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.
