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.

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

Support for specifying the code model #15698

Merged
merged 1 commit into from
Jul 17, 2014
Merged

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Jul 15, 2014

The default code model is usually unsuitable for kernels,
so we add an option to specify which model we want.

Testing for this would be fragile and very architecture specific and is better left to LLVM.

The default code model is usually unsuitable for kernels,
so we add an option to specify which model we want.
@alexcrichton
Copy link
Member

I'm not personally that familiar with what a code model is, could you explain it a bit more? Sometimes options like this are best done as crate attributes rather than flags, especially if one crate always wants the same configuration no matter what its compiled for.

@Zoxc
Copy link
Contributor Author

Zoxc commented Jul 16, 2014

See 3.5.1 of the System V Application Binary Interface - http://www.x86-64.org/documentation/abi.pdf

It's basically an optimization that allows you to avoid writing mov rax, 64bit-immediate for referencing symbols (which is that the large model does). However it places restrictions on where symbols can be in memory. The code model to use would be architecture specific and depend on the virtual size of binaries which in turn depends on the code model and an particular configuration. I don't think LLVM will always pick a suitable model, so I think this is better left as a command line option.

bors added a commit that referenced this pull request Jul 17, 2014
The default code model is usually unsuitable for kernels,
so we add an option to specify which model we want.

Testing for this would be fragile and very architecture specific and is better left to LLVM.
@bors bors closed this Jul 17, 2014
@bors bors merged commit 0a31060 into rust-lang:master Jul 17, 2014
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 13, 2023
…re_lenient, r=Veykril

fix: allow more kinds of if let patterns in guarded return assist

Removes the checks that require the pattern to be a tuple struct with exactly 1 field that is unqualified and has an identifier pattern in it. I'm not sure if there should be more checks in place but they seem unnecessary now?

Closes rust-lang#15695
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants