Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Optimize native wrappers #1192

Closed
nikomatsakis opened this issue Nov 19, 2011 · 3 comments
Closed

Optimize native wrappers #1192

nikomatsakis opened this issue Nov 19, 2011 · 3 comments
Assignees
@nikomatsakis
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@nikomatsakis
Copy link
Contributor

As of @b6af844, we generate Rust wrappers for native functions. These allow for easy interop with Rust code but introduce some performance inefficiencies. This could be improved in two ways:

  1. Inline the calls to the wrapper functions. Ideally, this would be done at the LLVM level as part of a general inlining pass, so as not to complicate trans.
  2. Specialize to the i386 architecture (and possibly other targets as well). In i386 in particular, we could eliminate some copies by writing the function arguments directly into memory allocated using alloc_on_c_stack(), as we used to do originally. This was removed because it does not apply to x86_64 nor does it work well for stdcall functions (layout on stack is different), whereas the current technique lets LLVM handle details of the target calling convention. Nonetheless, if it is deemed worthwhile, we could specialize the case of cdecl functions on i386 (and stdcall, for that matter).
@brson
Copy link
Contributor

brson commented Mar 6, 2012

The most unfortunate thing about our current scheme is the cache misses (#1801)

@ghost ghost assigned nikomatsakis Apr 12, 2012
@catamorphism
Copy link
Contributor

Doesn't seem like a backwards-compatibility thing. Nominating for milestone 5, production-ready.

@graydon
Copy link
Contributor

graydon commented May 30, 2013

native wrappers are all going away, closing this, made obsolete by #6661

@graydon graydon closed this as completed May 30, 2013
@durka durka mentioned this issue Jan 13, 2016
Merged
bors added a commit that referenced this issue Mar 6, 2016
@bors
Auto merge of #30884 - durka:inclusive-ranges, r=aturon
8484831 
This PR implements [RFC 1192](https://github.com/rust-lang/rfcs/blob/master/text/1192-inclusive-ranges.md), which is triple-dot syntax for inclusive range expressions. The new stuff is behind two feature gates (one for the syntax and one for the std::ops types). This replaces the deprecated functionality in std::iter. Along the way I simplified the desugaring for all ranges.

This is my first contribution to rust which changes more than one character outside of a test or comment, so please review carefully! Some of the individual commit messages have more of my notes. Also thanks for putting up with my dumb questions in #rust-internals.

- For implementing `std::ops::RangeInclusive`, I took @Stebalien's suggestion from rust-lang/rfcs#1192 (comment). It seemed to me to make the implementation easier and increase type safety. If that stands, the RFC should be amended to avoid confusion.
- I also kind of like @glaebhoerl's [idea](rust-lang/rfcs#1254 (comment)), which is unified inclusive/exclusive range syntax something like `x>..=y`. We can experiment with this while everything is behind a feature gate.
- There are a couple of FIXMEs left (see the last commit). I didn't know what to do about `RangeArgument` and I haven't added `Index` impls yet. Those should be discussed/finished before merging.

cc @gankro since you [complained](https://www.reddit.com/r/rust/comments/3xkfro/what_happened_to_inclusive_ranges/cy5j0yq)
cc #27777 #30877 #1192 rust-lang/rfcs#1254
relevant to #28237 (tracking issue)
bjorn3 added a commit to bjorn3/rust that referenced this issue Sep 19, 2021
@bjorn3
Add warning to the jit mode section of the usage docs
c11d8f5 
Closes rust-lang#1192
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@tedinski
Allow cargo-kani to run outside a Cargo project (rust-lang#1192)
0805270 
* Allow cargo-kani to run outside a Cargo project

* Add test in docker
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nikomatsakis nikomatsakis

Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@graydon @brson @nikomatsakis @catamorphism