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.
asm: Add a kreg0 register class on x86 which includes k0
Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.
Fixes#94977
Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.
Fixes#94977
Allow self-profiler to only record potentially costly arguments when argument recording is turned on
As discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns/near/277304909) with `@wesleywiser,` I'd like to record proc-macro expansions in the self-profiler, with some detailed data (per-expansion spans for example, to follow #95473).
At the same time, I'd also like to avoid doing expensive things when tracking a generic activity's arguments, if they were not specifically opted into the event filter mask, to allow the self-profiler to be used in hotter contexts.
This PR tries to offer:
- a way to ensure a closure to record arguments will only be called in that situation, so that potentially costly arguments can still be recorded when needed. With the additional requirement that, if possible, it would offer a way to record non-owned data without adding many `generic_activity_with_arg_{...}`-style methods. This lead to the `generic_activity_with_arg_recorder` single entry-point, and the closure parameter would offer the new methods, able to be executed in a context where costly argument could be created without disturbing the profiled piece of code.
- some facilities/patterns allowing to record more rustc specific data in this situation, without making `rustc_data_structures` where the self-profiler is defined, depend on other rustc crates (causing circular dependencies): in particular, spans. They are quite tricky to turn into strings (if the default `Debug` impl output does not match the context one needs them for), and since I'd also like to avoid the allocation there when arg recording is turned off today, that has turned into another flexibility requirement for the API in this PR (separating the span-specific recording into an extension trait). **edit**: I've removed this from the PR so that it's easier to review, and opened https://github.com/rust-lang/rust/pull/95739.
- allow for extensibility in the future: other ways to record arguments, or additional data attached to them could be added in the future (e.g. recording the argument's name as well as its data).
Some areas where I'd love feedback:
- the API and names: the `EventArgRecorder` and its method for example. As well as the verbosity that comes from the increased flexibility.
- if I should convert the existing `generic_activity_with_arg{s}` to just forward to `generic_activity_with_arg_recorder` + `recorder.record_arg` (or remove them altogether ? Probably not): I've used the new API in the simple case I could find of allocating for an arg that may not be recorded, and the rest don't seem costly.
- [x] whether this API should panic if no arguments were recorded by the user-provided closure (like this PR currently does: it seems like an error to use an API dedicated to record arguments but not call the methods to then do so) or if this should just record a generic activity without arguments ?
- whether the `record_arg` function should be `#[inline(always)]`, like the `generic_activity_*` functions ?
As mentioned, r? `@wesleywiser` following our recent discussion.
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.
This was a workaround for compiling proc macros resulting in an abi
incompatibility. By passing --target proc macros will be built by the
llvm backend. This is no longer necessary as the abi incompatibility has
since been fixed.
