[Bug target/110899] New: RFE: Attributes preserve_most and preserve_all

2023-08-04 Thread elver at google dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899

Bug ID: 110899
   Summary: RFE: Attributes preserve_most and preserve_all
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elver at google dot com
  Target Milestone: ---

Clang/LLVM implements the function attributes "preserve_most" and
"preserve_all":

[1] preserve_most: "On X86-64 and AArch64 targets, this attribute changes the
calling convention of a function. The preserve_most calling convention attempts
to make the code in the caller as unintrusive as possible. This convention
behaves identically to the C calling convention on how arguments and return
values are passed, but it uses a different set of caller/callee-saved
registers. This alleviates the burden of saving and recovering a large register
set before and after the call in the caller. If the arguments are passed in
callee-saved registers, then they will be preserved by the callee across the
call. This doesn’t apply for values returned in callee-saved registers.

- On X86-64 the callee preserves all general purpose registers, except for R11.
R11 can be used as a scratch register. Floating-point registers (XMMs/YMMs) are
not preserved and need to be saved by the caller.

- On AArch64 the callee preserve all general purpose registers, except X0-X8
and X16-X18."

[2] preserve_all: "On X86-64 and AArch64 targets, this attribute changes the
calling convention of a function. The preserve_all calling convention attempts
to make the code in the caller even less intrusive than the preserve_most
calling convention. This calling convention also behaves identical to the C
calling convention on how arguments and return values are passed, but it uses a
different set of caller/callee-saved registers. This removes the burden of
saving and recovering a large register set before and after the call in the
caller. If the arguments are passed in callee-saved registers, then they will
be preserved by the callee across the call. This doesn’t apply for values
returned in callee-saved registers.

- On X86-64 the callee preserves all general purpose registers, except for R11.
R11 can be used as a scratch register. Furthermore it also preserves all
floating-point registers (XMMs/YMMs).

- On AArch64 the callee preserve all general purpose registers, except X0-X8
and X16-X18. Furthermore it also preserves lower 128 bits of V8-V31 SIMD -
floating point registers."

[1] https://clang.llvm.org/docs/AttributeReference.html#preserve-most
[2] https://clang.llvm.org/docs/AttributeReference.html#preserve-all


These attributes, esp. preserve_most, provides a convenient way to optimize the
generated code for calls to rarely taken slow paths, such as error-reporting
functions. Recently, we're looking to make use of this in the Linux kernel [3],
with potentially additional usecases being discussed.

[3] https://lkml.kernel.org/r/20230804090621.400-1-el...@google.com

[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1

2023-02-14 Thread elver at google dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777

--- Comment #8 from Marco Elver  ---
Thanks for the quick turnaround!

[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1

2023-02-13 Thread elver at google dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108777

--- Comment #3 from Marco Elver  ---
(In reply to Jakub Jelinek from comment #2)
> Marco, is this what you are looking for?

Yes, looks good - the tests verify the behaviour I'd expect. Thanks!

[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

2021-06-23 Thread elver at google dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223

--- Comment #19 from Marco Elver  ---
(In reply to Fangrui Song from comment #18)
[...] 
> Our problem is that a boolean attribute with 1 bit information cannot
> express whether a neg attribute function can be inlined into a pos attribute
> function.
> 
> Let's agree to disagree. I don't see why a no_profile_instrument_function
> function suppress inlining into a function without the attribute. For the
> use cases where users want to suppress inlining, they can add noinline. What
> I worry about is that now GCC has an attitude and if the LLVM side doesn't
> follow it is like diverging. However, the GCC patch is still in review. I
> think a similar topic may need to be raided on llvm-dev side as I feel this
> is the tip of the iceberg - more attributes can be similarly leveraged. So,
> how about a llvm-dev discussion?

I have mentioned this several times now, but it seems nobody is listening: It's
_not_ about inlining -- the inlining discussion is about a particular
implementation strategy.

It's about the _contract an attribute promises_, which is treating the code in
the function a certain way (e.g. do not instrument). That can be done by
either: a) even if the code is inlined, respect the original attribute for the
inlined code (e.g. do not instrument), or b) just don't inline.

It looks like (b) is easier to do. I probably do not understand how hard (a)
is.

If you break the contract because it's too hard to do (a), then that's your
problem. Just don't break the contract. Because that's how we get
impossible-to-diagnose bugs.

Correctness comes first: if it is impossible for a user to reason about the
behaviour of their code due to unspecified behaviour (viz. breaking the
contract) of an attribute, then the code is doomed to be incorrect. Therefore,
do _not_ implement attributes with either unspecified or ridiculously specified
behaviour.

Ridiculous in this case is saying "this attribute only does what it promises if
you also add noinline". It's ridiculous, because the user will then rightfully
wonder "?!?!? Why doesn't it imply noinline then?!?!?!".

Thanks.