This commit updates this method implementation to return an `RValue` of
the given pointee type.
While this parameter does not seem to have much significance at the
moment, it will likely become important as cg_llvm and cg_ssa migrate to
LLVM opaque pointers and get rid of pointercasts.
The parameter name isn't very descriptive, but it actually supposed to
take a pointee type. When calling it ourselves, we've been passing a
*pointer* type, which made it impossible to make any meaningful uses of
this parameter in the method implementation. This commit intends to
rectify that.
This commit updates `<Builder as AsmBuilderMethods>::codegen_inline_asm`
to convert `sym` operands into `"X" (&func_or_static)` input operands
to indicate the dependency on the referenced symbols and prevent them
from being eliminated.
We follow the suit of the LLVM codegen with a mixture of its differing
techniques for `asm!` and `global_asm!`. The codegen module generates
input operands for the `sym` operands (as in `asm!` in cg_llvm).
However, the codegen module replaces all placeholders with mangled
symbol names before passing the assembly template string to the backend
(as in `global_asm!` in cg_llvm), which means these input operands are
never referenced in the final assembly template string.
Unlike the LLVM codegen, the input operand constraint must be `X`
instead of `s`. If the `s` constraint is used, GCC will employ checks to
make sure that the operand can really be represented by a simple
symbolic constant, thus rejecting symbols requiring GOT, etc. to
resolve. Such checks are unnecessary for Rust `sym` as it's up to
programmers to handle such complex cases, e.g., by manually appending
GOT addressing modifiers to the substituted symbol names.
Using the `X` constraint doesn't seem to generate any extra code, so
this will not compromise the property of naked functions.
Updates their unsigned code paths to use the `Builder::gcc_` methods
that automatically lower non-native integer operations to native ones.
Also updates the signed code path of `saturating_add` to support non-
native integer types. That of `saturating_sub` already supports this,
so no major changes have been made.
Implement -Z oom=panic
This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596).
Perf and binary size tests show negligible impact.
This commit makes `AdtDef` use `Interned`. Much the commit is tedious
changes to introduce getter functions. The interesting changes are in
`compiler/rustc_middle/src/ty/adt.rs`.
Clarify `Layout` interning.
`Layout` is another type that is sometimes interned, sometimes not, and
we always use references to refer to it so we can't take any advantage
of the uniqueness properties for hashing or equality checks.
This commit renames `Layout` as `LayoutS`, and then introduces a new
`Layout` that is a newtype around an `Interned<LayoutS>`. It also
interns more layouts than before. Previously layouts within layouts
(via the `variants` field) were never interned, but now they are. Hence
the lifetime on the new `Layout` type.
Unlike other interned types, these ones are in `rustc_target` instead of
`rustc_middle`. This reflects the existing structure of the code, which
does layout-specific stuff in `rustc_target` while `TyAndLayout` is
generic over the `Ty`, allowing the type-specific stuff to occur in
`rustc_middle`.
The commit also adds a `HashStable` impl for `Interned`, which was
needed. It hashes the contents, unlike the `Hash` impl which hashes the
pointer.
r? `@fee1-dead`
`Layout` is another type that is sometimes interned, sometimes not, and
we always use references to refer to it so we can't take any advantage
of the uniqueness properties for hashing or equality checks.
This commit renames `Layout` as `LayoutS`, and then introduces a new
`Layout` that is a newtype around an `Interned<LayoutS>`. It also
interns more layouts than before. Previously layouts within layouts
(via the `variants` field) were never interned, but now they are. Hence
the lifetime on the new `Layout` type.
Unlike other interned types, these ones are in `rustc_target` instead of
`rustc_middle`. This reflects the existing structure of the code, which
does layout-specific stuff in `rustc_target` while `TyAndLayout` is
generic over the `Ty`, allowing the type-specific stuff to occur in
`rustc_middle`.
The commit also adds a `HashStable` impl for `Interned`, which was
needed. It hashes the contents, unlike the `Hash` impl which hashes the
pointer.
Currently some `Allocation`s are interned, some are not, and it's very
hard to tell at a use point which is which.
This commit introduces `ConstAllocation` for the known-interned ones,
which makes the division much clearer. `ConstAllocation::inner()` is
used to get the underlying `Allocation`.
In some places it's natural to use an `Allocation`, in some it's natural
to use a `ConstAllocation`, and in some places there's no clear choice.
I've tried to make things look as nice as possible, while generally
favouring `ConstAllocation`, which is the type that embodies more
information. This does require quite a few calls to `inner()`.
The commit also tweaks how `PartialOrd` works for `Interned`. The
previous code was too clever by half, building on `T: Ord` to make the
code shorter. That caused problems with deriving `PartialOrd` and `Ord`
for `ConstAllocation`, so I changed it to build on `T: PartialOrd`,
which is slightly more verbose but much more standard and avoided the
problems.
Direct users towards using Rust target feature names in CLI
This PR consists of a couple of changes on how we handle target features.
In particular there is a bug-fix wherein we avoid passing through features that aren't prefixed by `+` or `-` to LLVM. These appear to be causing LLVM to assert, which is pretty poor a behaviour (and also makes it pretty clear we expect feature names to be prefixed).
The other commit, I anticipate to be somewhat more controversial is outputting a warning when users specify a LLVM-specific, or otherwise unknown, feature name on the CLI. In those situations we request users to either replace it with a known Rust feature name (e.g. `bmi` -> `bmi1`) or file a feature request. I've a couple motivations for this: first of all, if users are specifying these features on the command line, I'm pretty confident there is also a need for these features to be usable via `#[cfg(target_feature)]` machinery. And second, we're growing a fair number of backends recently and having ability to provide some sort of unified-ish interface in this place seems pretty useful to me.
Sponsored by: standard.ai
