Support for specifying the code model #15698
Conversation
The default code model is usually unsuitable for kernels, so we add an option to specify which model we want.
|
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. |
|
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. |
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.
…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
ping rust-lang/rust-clippy#15690 changelog: none
3 participants
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.