Re: [x86-64] RFC: Add nosse abi attribute
Michael Matz via Gcc-patches writes:
> Hello,
>
> the ELF psABI for x86-64 doesn't have any callee-saved SSE
> registers (there were actual reasons for that, but those don't
> matter anymore). This starts to hurt some uses, as it means that
> as soon as you have a call (say to memmove/memcpy, even if
> implicit as libcall) in a loop that manipulates floating point
> or vector data you get saves/restores around those calls.
>
> But in reality many functions can be written such that they only need
> to clobber a subset of the 16 XMM registers (or do the save/restore
> themself in the codepaths that needs them, hello memcpy again).
> So we want to introduce a way to specify this, via an ABI attribute
> that basically says "doesn't clobber the high XMM regs".
>
> I've opted to do only the obvious: do something special only for
> xmm8 to xmm15, without a way to specify the clobber set in more detail.
> I think such half/half split is reasonable, and as I don't want to
> change the argument passing anyway (whose regs are always clobbered)
> there isn't that much wiggle room anyway.
>
> I chose to make it possible to write function definitions with that
> attribute with GCC adding the necessary callee save/restore code in
> the xlogue itself. Carefully note that this is only possible for
> the SSE2 registers, as other parts of them would need instructions
> that are only optional. When a function doesn't contain calls to
> unknown functions we can be a bit more lenient: we can make it so that
> GCC simply doesn't touch xmm8-15 at all, then no save/restore is
> necessary. If a function contains calls then GCC can't know which
> parts of the XMM regset is clobbered by that, it may be parts
> which don't even exist yet (say until avx2048 comes out), so we must
> restrict ourself to only save/restore the SSE2 parts and then of course
> can only claim to not clobber those parts.
>
> To that end I introduce actually two related attributes (for naming
> see below):
> * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
> * noanysseclobber: claims (and ensures) that nothing of any of the
> registers overlapping xmm8-15 is clobbered (not even future, as of
> yet unknown, parts)
>
> Ensuring the first is simple: potentially add saves/restore in xlogue
> (e.g. when xmm8 is either used explicitely or implicitely by a call).
> Ensuring the second comes with more: we must also ensure that no
> functions are called that don't guarantee the same thing (in addition
> to just removing all xmm8-15 parts alltogether from the available
> regsters).
>
> See also the added testcases for what I intended to support.
>
> I chose to use the new target independend function-abi facility for
> this. I need some adjustments in generic code:
> * the "default_abi" is actually more like a "current" abi: it happily
> changes its contents according to conditional_register_usage,
> and other code assumes that such changes do propagate.
> But if that conditonal_reg_usage is actually done because the current
> function is of a different ABI, then we must not change default_abi.
> * in insn_callee_abi we do look at a potential fndecl for a call
> insn (only set when -fipa-ra), but doesn't work for calls through
> pointers and (as said) is optional. So, also always look at the
> called functions type (it's always recorded in the MEM_EXPR for
> non-libcalls), before asking the target.
> (The function-abi accessors working on trees were already doing that,
> its just the RTL accessor that missed this)
> [...]
> diff --git a/gcc/function-abi.cc b/gcc/function-abi.cc
> index 2ab9b2c5649..efbe114218c 100644
> --- a/gcc/function-abi.cc
> +++ b/gcc/function-abi.cc
> @@ -42,6 +42,26 @@ void
> predefined_function_abi::initialize (unsigned int id,
>const_hard_reg_set full_reg_clobbers)
> {
> + /* Don't reinitialize an ABI struct. We might be called from reinit_regs
> + from the targets conditional_register_usage hook which might depend
> + on cfun and might have changed the global register sets according
> + to that functions ABI already. That's not the default ABI anymore.
> +
> + XXX only avoid this if we're reinitializing the default ABI, and the
> + current function is _not_ of the default ABI. That's for
> + backward compatibility where some backends modify the regsets with
> + the exception that those changes are then reflected also in the default
> + ABI (which rather is then the "current" ABI). E.g. x86_64 with the
> + ms_abi vs sysv attribute. They aren't reflected by separate ABI
> + structs, but handled different. The "default" ABI hence changes
> + back and forth (and is expected to!) between a ms_abi and a sysv
> + function. */
The default ABI is also the eh_edge_abi, and so describes the set of
registers that are preserved or clobbered across EH edges. If changing
between ms_abi and sysv changes the "default" A
Re: [x86-64] RFC: Add nosse abi attribute
On Tue, 11 Jul 2023, Michael Matz wrote: > Hey, > > On Tue, 11 Jul 2023, Alexander Monakov via Gcc-patches wrote: > > > > > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered > > > > > > > > This is the weak/active form; I'd suggest "preserve_high_sse". > > > > > > But it preserves only the low parts :-) You swapped the two in your > > > mind when writing the reply? > > > > Ahhh. By "high SSE" I mean the high-numbered SSE regs, i.e. xmm8-15, not > > the higher halves of (unspecified subset of) SSE regs. > > Ah, gotcha :-) It just shows that all these names are confusing. Maybe > I'll just go with "attribute1" and "attribute2" and rely on docu. (SCNR) Heh, that reminds me that decimal digits are allowed in attribute names. Let me offer "preserve_xmm_8_15" and "only_xmm_0_7" then. One more thing to keep in mind is interaction with SSE-AVX transition. If the function with a new attribute is using classic non-VEX-encoded SSE, but its caller is using 256-bit ymm0-15, it will incur a substantial penalty on Intel CPUs. There's no penalty on AMD (afaik) and no penalty for zmm16-31, since those are inaccessible in non-EVEX code. Alexander
Re: [x86-64] RFC: Add nosse abi attribute
Hey, On Tue, 11 Jul 2023, Alexander Monakov via Gcc-patches wrote: > > > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered > > > > > > This is the weak/active form; I'd suggest "preserve_high_sse". > > > > But it preserves only the low parts :-) You swapped the two in your > > mind when writing the reply? > > Ahhh. By "high SSE" I mean the high-numbered SSE regs, i.e. xmm8-15, not > the higher halves of (unspecified subset of) SSE regs. Ah, gotcha :-) It just shows that all these names are confusing. Maybe I'll just go with "attribute1" and "attribute2" and rely on docu. (SCNR) Ciao, Michael.
Re: [x86-64] RFC: Add nosse abi attribute
On Tue, 11 Jul 2023, Michael Matz wrote: > > > To that end I introduce actually two related attributes (for naming > > > see below): > > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered > > > > This is the weak/active form; I'd suggest "preserve_high_sse". > > But it preserves only the low parts :-) You swapped the two in your > mind when writing the reply? Ahhh. By "high SSE" I mean the high-numbered SSE regs, i.e. xmm8-15, not the higher halves of (unspecified subset of) SSE regs. If you look from AVX viewpoint, yes, it preserves lower 128 bits of the high-numbered vector registers. Alexander
Re: [x86-64] RFC: Add nosse abi attribute
Hello,
On Mon, 10 Jul 2023, Alexander Monakov wrote:
> I think the main question is why you're going with this (weak) form
> instead of the (strong) form "may only clobber the low XMM regs":
I want to provide both. One of them allows more arbitrary function
definitions, the other allows more register (parts) to be preserved. I
feel both have their place.
> as Richi noted, surely for libcalls we'd like to know they preserve
> AVX-512 mask registers as well?
Yeah, mask registers. I'm still pondering this. We would need to split
the 8 maskregs into two parts. Hmm.
> Note this interacts with anything that interposes between the caller
> and the callee, like the Glibc lazy binding stub (which used to
> zero out high halves of 512-bit arguments in ZMM registers).
> Not an immediate problem for the patch, just something to mind perhaps.
Yeah, needs to be kept in mind indeed. Anything coming in between the
caller and a so-marked callee needs to preserve things.
> > I chose to make it possible to write function definitions with that
> > attribute with GCC adding the necessary callee save/restore code in
> > the xlogue itself.
>
> But you can't trivially restore if the callee is sibcalling — what
> happens then (a testcase might be nice)?
I hoped early on that the generic code that prohibits sibcalls between
call sites of too "different" ABIs would deal with this, and then forgot
to check. Turns out you had a good hunch here, it actually does a
sibcall, destroying the guarantees. Thanks! :)
> > Carefully note that this is only possible for the SSE2 registers, as
> > other parts of them would need instructions that are only optional.
>
> What is supposed to happen on 32-bit x86 with -msse -mno-sse2?
Hmm. I feel the best answer here is "that should error out". I'll add a
test and adjust patch if necessary.
> > When a function doesn't contain calls to
> > unknown functions we can be a bit more lenient: we can make it so that
> > GCC simply doesn't touch xmm8-15 at all, then no save/restore is
> > necessary.
>
> What if the source code has a local register variable bound to xmm15,
> i.e. register double x asm("xmm15"); asm("..." : "+x"(x)); ?
Makes a good testcase as well. My take: it's acceptable with the
only-sse2-preserved attribute (xmm15 will in this case be saved/restored),
and should be an error with the everything-preserved attribute (maybe we
can make an exception as here we only specify an XMM reg, instead of
larger parts).
> > To that end I introduce actually two related attributes (for naming
> > see below):
> > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
>
> This is the weak/active form; I'd suggest "preserve_high_sse".
But it preserves only the low parts :-) You swapped the two in your
mind when writing the reply?
> > I would welcome any comments, about the names, the approach, the attempt
> > at documenting the intricacies of these attributes and anything.
>
> I hope the new attributes are supposed to be usable with function
> pointers? From the code it looks that way, but the documentation doesn't
> promise that.
Yes, like all ABI influencing attributes they _have_ to be part of the
functions type (and hence transfer to function pointers), with appropriate
incompatible-conversion errors and warnings at the appropriate places. (I
know that this isn't always the way we're dealing with ABI-infuencing
attributes, and often refer to a decl only. All those are actual bugs.)
And yes, I will adjust the docu to be explicit about this.
Ciao,
Michael.
Re: [x86-64] RFC: Add nosse abi attribute
Hello, On Tue, 11 Jul 2023, Jan Hubicka wrote: > > > > When a function doesn't contain calls to > > > > unknown functions we can be a bit more lenient: we can make it so that > > > > GCC simply doesn't touch xmm8-15 at all, then no save/restore is > > > > necessary. > > One may also take into account that first 8 registers are cheaper to > encode than the later 8, so perhaps we may want to choose range that > contains both. There is actually none in the low range that's usable. xmm0/1 are used for return values and xmm2-7 are used for argument passing. Arguments are by default callee clobbered, and we do not want to change this (or limit the number of register arguments for the alternate ABI). Ciao, Michael.
Re: [x86-64] RFC: Add nosse abi attribute
On Tue, 11 Jul 2023, Richard Biener wrote: > > > If a function contains calls then GCC can't know which > > > parts of the XMM regset is clobbered by that, it may be parts > > > which don't even exist yet (say until avx2048 comes out), so we must > > > restrict ourself to only save/restore the SSE2 parts and then of course > > > can only claim to not clobber those parts. > > > > Hm, I guess this is kinda the reason a "weak" form is needed. But this > > highlights the difference between the two: the "weak" form will actively > > preserve some state (so it cannot preserve future extensions), while > > the "strong" form may just passively not touch any state, preserving > > any state it doesn't know about. > > > > > To that end I introduce actually two related attributes (for naming > > > see below): > > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered > > > > This is the weak/active form; I'd suggest "preserve_high_sse". > > Isn't it the opposite? "preserves_low_sse", unless you suggest > the name applies to the caller which has to preserve high parts > when calling nosseclobber. This is the form where the function annnotated with this attribute consumes 128 bytes on the stack to "blindly" save/restore xmm8-15 if it calls anything with a vanilla ABI. (actually thinking about it more, I'd like to suggest shelving this part and only implement the zero-cost variant, noanysseclobber) > > > * noanysseclobber: claims (and ensures) that nothing of any of the > > > registers overlapping xmm8-15 is clobbered (not even future, as of > > > yet unknown, parts) > > > > This is the strong/passive form; I'd suggest "only_low_sse". > > Likewise. Sorry if I managed to sow confusion here. In my mind, this is the form where only xmm0-xmm7 can be written in the function annotated with the attribute, including its callees. I was thinking that writing to zmm16-31 would be disallowed too. The initial example was memcpy, where eight vector registers are sufficient for the job. > As for mask registers I understand we'd have to split the 8 register > set into two halves to make the same approach work, otherwise > we'd have no registers left to allocate from. I'd suggest to look how many mask registers OpenMP SIMD AVX-512 clones can receive as implicit arguments, as one data point. Alexander
Re: [x86-64] RFC: Add nosse abi attribute
> > > When a function doesn't contain calls to > > > unknown functions we can be a bit more lenient: we can make it so that > > > GCC simply doesn't touch xmm8-15 at all, then no save/restore is > > > necessary. One may also take into account that first 8 registers are cheaper to encode than the later 8, so perhaps we may want to choose range that contains both. Honza
Re: [x86-64] RFC: Add nosse abi attribute
On Mon, Jul 10, 2023 at 9:08 PM Alexander Monakov via Gcc-patches
wrote:
>
>
> On Mon, 10 Jul 2023, Michael Matz via Gcc-patches wrote:
>
> > Hello,
> >
> > the ELF psABI for x86-64 doesn't have any callee-saved SSE
> > registers (there were actual reasons for that, but those don't
> > matter anymore). This starts to hurt some uses, as it means that
> > as soon as you have a call (say to memmove/memcpy, even if
> > implicit as libcall) in a loop that manipulates floating point
> > or vector data you get saves/restores around those calls.
> >
> > But in reality many functions can be written such that they only need
> > to clobber a subset of the 16 XMM registers (or do the save/restore
> > themself in the codepaths that needs them, hello memcpy again).
> > So we want to introduce a way to specify this, via an ABI attribute
> > that basically says "doesn't clobber the high XMM regs".
>
> I think the main question is why you're going with this (weak) form
> instead of the (strong) form "may only clobber the low XMM regs":
> as Richi noted, surely for libcalls we'd like to know they preserve
> AVX-512 mask registers as well?
>
> (I realize this is partially answered later)
>
> Note this interacts with anything that interposes between the caller
> and the callee, like the Glibc lazy binding stub (which used to
> zero out high halves of 512-bit arguments in ZMM registers).
> Not an immediate problem for the patch, just something to mind perhaps.
>
> > I've opted to do only the obvious: do something special only for
> > xmm8 to xmm15, without a way to specify the clobber set in more detail.
> > I think such half/half split is reasonable, and as I don't want to
> > change the argument passing anyway (whose regs are always clobbered)
> > there isn't that much wiggle room anyway.
> >
> > I chose to make it possible to write function definitions with that
> > attribute with GCC adding the necessary callee save/restore code in
> > the xlogue itself.
>
> But you can't trivially restore if the callee is sibcalling — what
> happens then (a testcase might be nice)?
>
> > Carefully note that this is only possible for
> > the SSE2 registers, as other parts of them would need instructions
> > that are only optional.
>
> What is supposed to happen on 32-bit x86 with -msse -mno-sse2?
>
> > When a function doesn't contain calls to
> > unknown functions we can be a bit more lenient: we can make it so that
> > GCC simply doesn't touch xmm8-15 at all, then no save/restore is
> > necessary.
>
> What if the source code has a local register variable bound to xmm15,
> i.e. register double x asm("xmm15"); asm("..." : "+x"(x)); ?
> Probably "dont'd do that", i.e. disallow that in the documentation?
>
> > If a function contains calls then GCC can't know which
> > parts of the XMM regset is clobbered by that, it may be parts
> > which don't even exist yet (say until avx2048 comes out), so we must
> > restrict ourself to only save/restore the SSE2 parts and then of course
> > can only claim to not clobber those parts.
>
> Hm, I guess this is kinda the reason a "weak" form is needed. But this
> highlights the difference between the two: the "weak" form will actively
> preserve some state (so it cannot preserve future extensions), while
> the "strong" form may just passively not touch any state, preserving
> any state it doesn't know about.
>
> > To that end I introduce actually two related attributes (for naming
> > see below):
> > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
>
> This is the weak/active form; I'd suggest "preserve_high_sse".
Isn't it the opposite? "preserves_low_sse", unless you suggest
the name applies to the caller which has to preserve high parts
when calling nosseclobber.
> > * noanysseclobber: claims (and ensures) that nothing of any of the
> > registers overlapping xmm8-15 is clobbered (not even future, as of
> > yet unknown, parts)
>
> This is the strong/passive form; I'd suggest "only_low_sse".
Likewise.
As for mask registers I understand we'd have to split the 8 register
set into two halves to make the same approach work, otherwise
we'd have no registers left to allocate from.
> > Ensuring the first is simple: potentially add saves/restore in xlogue
> > (e.g. when xmm8 is either used explicitely or implicitely by a call).
> > Ensuring the second comes with more: we must also ensure that no
> > functions are called that don't guarantee the same thing (in addition
> > to just removing all xmm8-15 parts alltogether from the available
> > regsters).
> >
> > See also the added testcases for what I intended to support.
> >
> > I chose to use the new target independend function-abi facility for
> > this. I need some adjustments in generic code:
> > * the "default_abi" is actually more like a "current" abi: it happily
> > changes its contents according to conditional_register_usage,
> > and other code assumes that such changes do propagate.
> > But if that conditonal_reg_usage is ac
Re: [x86-64] RFC: Add nosse abi attribute
On Tue, Jul 11, 2023 at 10:53 AM Jan Hubicka wrote: > > > > > FWIW, this particular patch was regstrapped on x86-64-linux > > > > with trunk from a week ago (and sniff-tested on current trunk). > > > > > > This looks really cool. > > > > The biggest benefit might be from IPA with LTO where we'd carefully place > > those > > attributes at WPA time (at that time tieing our hands for later). > > Within single partition IRA already propagates the knowledge about > callee-clobbered registers. > > Across partition we already automatically enable regparm with -m32 > see ix86_function_regparm and tests for target->local and > can_change_attribute > > Enabling SSE at the same spot should be easy. It's probably slightly different since we want to enable it for a "leaf" sub-callgraph (or where edges to extern have the appropriate ABI by means of attributes) irrespective of whether the functions are exported (we're adding to the callee save set, which is ABI compatible with the default ABI). But yes, that place would be appropriate. Richard. > > Honza
Re: [x86-64] RFC: Add nosse abi attribute
> > > FWIW, this particular patch was regstrapped on x86-64-linux > > > with trunk from a week ago (and sniff-tested on current trunk). > > > > This looks really cool. > > The biggest benefit might be from IPA with LTO where we'd carefully place > those > attributes at WPA time (at that time tieing our hands for later). Within single partition IRA already propagates the knowledge about callee-clobbered registers. Across partition we already automatically enable regparm with -m32 see ix86_function_regparm and tests for target->local and can_change_attribute Enabling SSE at the same spot should be easy. Honza
Re: [x86-64] RFC: Add nosse abi attribute
On Mon, Jul 10, 2023 at 9:08 PM Alexander Monakov via Gcc-patches
wrote:
>
>
> On Mon, 10 Jul 2023, Michael Matz via Gcc-patches wrote:
>
> > Hello,
> >
> > the ELF psABI for x86-64 doesn't have any callee-saved SSE
> > registers (there were actual reasons for that, but those don't
> > matter anymore). This starts to hurt some uses, as it means that
> > as soon as you have a call (say to memmove/memcpy, even if
> > implicit as libcall) in a loop that manipulates floating point
> > or vector data you get saves/restores around those calls.
> >
> > But in reality many functions can be written such that they only need
> > to clobber a subset of the 16 XMM registers (or do the save/restore
> > themself in the codepaths that needs them, hello memcpy again).
> > So we want to introduce a way to specify this, via an ABI attribute
> > that basically says "doesn't clobber the high XMM regs".
>
> I think the main question is why you're going with this (weak) form
> instead of the (strong) form "may only clobber the low XMM regs":
> as Richi noted, surely for libcalls we'd like to know they preserve
> AVX-512 mask registers as well?
>
> (I realize this is partially answered later)
>
> Note this interacts with anything that interposes between the caller
> and the callee, like the Glibc lazy binding stub (which used to
> zero out high halves of 512-bit arguments in ZMM registers).
> Not an immediate problem for the patch, just something to mind perhaps.
>
> > I've opted to do only the obvious: do something special only for
> > xmm8 to xmm15, without a way to specify the clobber set in more detail.
> > I think such half/half split is reasonable, and as I don't want to
> > change the argument passing anyway (whose regs are always clobbered)
> > there isn't that much wiggle room anyway.
> >
> > I chose to make it possible to write function definitions with that
> > attribute with GCC adding the necessary callee save/restore code in
> > the xlogue itself.
>
> But you can't trivially restore if the callee is sibcalling — what
> happens then (a testcase might be nice)?
>
> > Carefully note that this is only possible for
> > the SSE2 registers, as other parts of them would need instructions
> > that are only optional.
>
> What is supposed to happen on 32-bit x86 with -msse -mno-sse2?
>
> > When a function doesn't contain calls to
> > unknown functions we can be a bit more lenient: we can make it so that
> > GCC simply doesn't touch xmm8-15 at all, then no save/restore is
> > necessary.
>
> What if the source code has a local register variable bound to xmm15,
> i.e. register double x asm("xmm15"); asm("..." : "+x"(x)); ?
> Probably "dont'd do that", i.e. disallow that in the documentation?
>
> > If a function contains calls then GCC can't know which
> > parts of the XMM regset is clobbered by that, it may be parts
> > which don't even exist yet (say until avx2048 comes out), so we must
> > restrict ourself to only save/restore the SSE2 parts and then of course
> > can only claim to not clobber those parts.
>
> Hm, I guess this is kinda the reason a "weak" form is needed. But this
> highlights the difference between the two: the "weak" form will actively
> preserve some state (so it cannot preserve future extensions), while
> the "strong" form may just passively not touch any state, preserving
> any state it doesn't know about.
>
> > To that end I introduce actually two related attributes (for naming
> > see below):
> > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
>
> This is the weak/active form; I'd suggest "preserve_high_sse".
>
> > * noanysseclobber: claims (and ensures) that nothing of any of the
> > registers overlapping xmm8-15 is clobbered (not even future, as of
> > yet unknown, parts)
>
> This is the strong/passive form; I'd suggest "only_low_sse".
>
> > Ensuring the first is simple: potentially add saves/restore in xlogue
> > (e.g. when xmm8 is either used explicitely or implicitely by a call).
> > Ensuring the second comes with more: we must also ensure that no
> > functions are called that don't guarantee the same thing (in addition
> > to just removing all xmm8-15 parts alltogether from the available
> > regsters).
> >
> > See also the added testcases for what I intended to support.
> >
> > I chose to use the new target independend function-abi facility for
> > this. I need some adjustments in generic code:
> > * the "default_abi" is actually more like a "current" abi: it happily
> > changes its contents according to conditional_register_usage,
> > and other code assumes that such changes do propagate.
> > But if that conditonal_reg_usage is actually done because the current
> > function is of a different ABI, then we must not change default_abi.
> > * in insn_callee_abi we do look at a potential fndecl for a call
> > insn (only set when -fipa-ra), but doesn't work for calls through
> > pointers and (as said) is optional. So, also always look at the
> > called functions t
Re: [x86-64] RFC: Add nosse abi attribute
On Mon, 10 Jul 2023, Alexander Monakov wrote: > > I chose to make it possible to write function definitions with that > > attribute with GCC adding the necessary callee save/restore code in > > the xlogue itself. > > But you can't trivially restore if the callee is sibcalling — what > happens then (a testcase might be nice)? Sorry, when the caller is doing the sibcall, not the callee. Alexander
Re: [x86-64] RFC: Add nosse abi attribute
On Mon, 10 Jul 2023, Michael Matz via Gcc-patches wrote:
> Hello,
>
> the ELF psABI for x86-64 doesn't have any callee-saved SSE
> registers (there were actual reasons for that, but those don't
> matter anymore). This starts to hurt some uses, as it means that
> as soon as you have a call (say to memmove/memcpy, even if
> implicit as libcall) in a loop that manipulates floating point
> or vector data you get saves/restores around those calls.
>
> But in reality many functions can be written such that they only need
> to clobber a subset of the 16 XMM registers (or do the save/restore
> themself in the codepaths that needs them, hello memcpy again).
> So we want to introduce a way to specify this, via an ABI attribute
> that basically says "doesn't clobber the high XMM regs".
I think the main question is why you're going with this (weak) form
instead of the (strong) form "may only clobber the low XMM regs":
as Richi noted, surely for libcalls we'd like to know they preserve
AVX-512 mask registers as well?
(I realize this is partially answered later)
Note this interacts with anything that interposes between the caller
and the callee, like the Glibc lazy binding stub (which used to
zero out high halves of 512-bit arguments in ZMM registers).
Not an immediate problem for the patch, just something to mind perhaps.
> I've opted to do only the obvious: do something special only for
> xmm8 to xmm15, without a way to specify the clobber set in more detail.
> I think such half/half split is reasonable, and as I don't want to
> change the argument passing anyway (whose regs are always clobbered)
> there isn't that much wiggle room anyway.
>
> I chose to make it possible to write function definitions with that
> attribute with GCC adding the necessary callee save/restore code in
> the xlogue itself.
But you can't trivially restore if the callee is sibcalling — what
happens then (a testcase might be nice)?
> Carefully note that this is only possible for
> the SSE2 registers, as other parts of them would need instructions
> that are only optional.
What is supposed to happen on 32-bit x86 with -msse -mno-sse2?
> When a function doesn't contain calls to
> unknown functions we can be a bit more lenient: we can make it so that
> GCC simply doesn't touch xmm8-15 at all, then no save/restore is
> necessary.
What if the source code has a local register variable bound to xmm15,
i.e. register double x asm("xmm15"); asm("..." : "+x"(x)); ?
Probably "dont'd do that", i.e. disallow that in the documentation?
> If a function contains calls then GCC can't know which
> parts of the XMM regset is clobbered by that, it may be parts
> which don't even exist yet (say until avx2048 comes out), so we must
> restrict ourself to only save/restore the SSE2 parts and then of course
> can only claim to not clobber those parts.
Hm, I guess this is kinda the reason a "weak" form is needed. But this
highlights the difference between the two: the "weak" form will actively
preserve some state (so it cannot preserve future extensions), while
the "strong" form may just passively not touch any state, preserving
any state it doesn't know about.
> To that end I introduce actually two related attributes (for naming
> see below):
> * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
This is the weak/active form; I'd suggest "preserve_high_sse".
> * noanysseclobber: claims (and ensures) that nothing of any of the
> registers overlapping xmm8-15 is clobbered (not even future, as of
> yet unknown, parts)
This is the strong/passive form; I'd suggest "only_low_sse".
> Ensuring the first is simple: potentially add saves/restore in xlogue
> (e.g. when xmm8 is either used explicitely or implicitely by a call).
> Ensuring the second comes with more: we must also ensure that no
> functions are called that don't guarantee the same thing (in addition
> to just removing all xmm8-15 parts alltogether from the available
> regsters).
>
> See also the added testcases for what I intended to support.
>
> I chose to use the new target independend function-abi facility for
> this. I need some adjustments in generic code:
> * the "default_abi" is actually more like a "current" abi: it happily
> changes its contents according to conditional_register_usage,
> and other code assumes that such changes do propagate.
> But if that conditonal_reg_usage is actually done because the current
> function is of a different ABI, then we must not change default_abi.
> * in insn_callee_abi we do look at a potential fndecl for a call
> insn (only set when -fipa-ra), but doesn't work for calls through
> pointers and (as said) is optional. So, also always look at the
> called functions type (it's always recorded in the MEM_EXPR for
> non-libcalls), before asking the target.
> (The function-abi accessors working on trees were already doing that,
> its just the RTL accessor that missed this)
>
> Accordingly I also implement some more
Re: [x86-64] RFC: Add nosse abi attribute
> Am 10.07.2023 um 17:56 schrieb Michael Matz via Gcc-patches
> :
>
> Hello,
>
> the ELF psABI for x86-64 doesn't have any callee-saved SSE
> registers (there were actual reasons for that, but those don't
> matter anymore). This starts to hurt some uses, as it means that
> as soon as you have a call (say to memmove/memcpy, even if
> implicit as libcall) in a loop that manipulates floating point
> or vector data you get saves/restores around those calls.
>
> But in reality many functions can be written such that they only need
> to clobber a subset of the 16 XMM registers (or do the save/restore
> themself in the codepaths that needs them, hello memcpy again).
> So we want to introduce a way to specify this, via an ABI attribute
> that basically says "doesn't clobber the high XMM regs".
>
> I've opted to do only the obvious: do something special only for
> xmm8 to xmm15, without a way to specify the clobber set in more detail.
> I think such half/half split is reasonable, and as I don't want to
> change the argument passing anyway (whose regs are always clobbered)
> there isn't that much wiggle room anyway.
What about xmm16 to xmm31 which AVX512 adds and any possible future additions
to the register file? (I suppose the any variant also covers zmm - and also
future widened variants?). What about AVX512 mask registers?
> I chose to make it possible to write function definitions with that
> attribute with GCC adding the necessary callee save/restore code in
> the xlogue itself. Carefully note that this is only possible for
> the SSE2 registers, as other parts of them would need instructions
> that are only optional. When a function doesn't contain calls to
> unknown functions we can be a bit more lenient: we can make it so that
> GCC simply doesn't touch xmm8-15 at all, then no save/restore is
> necessary. If a function contains calls then GCC can't know which
> parts of the XMM regset is clobbered by that, it may be parts
> which don't even exist yet (say until avx2048 comes out), so we must
> restrict ourself to only save/restore the SSE2 parts and then of course
> can only claim to not clobber those parts.
>
> To that end I introduce actually two related attributes (for naming
> see below):
> * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
> * noanysseclobber: claims (and ensures) that nothing of any of the
> registers overlapping xmm8-15 is clobbered (not even future, as of
> yet unknown, parts)
>
> Ensuring the first is simple: potentially add saves/restore in xlogue
> (e.g. when xmm8 is either used explicitely or implicitely by a call).
> Ensuring the second comes with more: we must also ensure that no
> functions are called that don't guarantee the same thing (in addition
> to just removing all xmm8-15 parts alltogether from the available
> regsters).
>
> See also the added testcases for what I intended to support.
>
> I chose to use the new target independend function-abi facility for
> this. I need some adjustments in generic code:
> * the "default_abi" is actually more like a "current" abi: it happily
> changes its contents according to conditional_register_usage,
> and other code assumes that such changes do propagate.
> But if that conditonal_reg_usage is actually done because the current
> function is of a different ABI, then we must not change default_abi.
> * in insn_callee_abi we do look at a potential fndecl for a call
> insn (only set when -fipa-ra), but doesn't work for calls through
> pointers and (as said) is optional. So, also always look at the
> called functions type (it's always recorded in the MEM_EXPR for
> non-libcalls), before asking the target.
> (The function-abi accessors working on trees were already doing that,
> its just the RTL accessor that missed this)
>
> Accordingly I also implement some more target hooks for function-abi.
> With that it's possible to also move the other ABI-influencing code
> of i386 to function-abi (ms_abi and friends). I have not done so for
> this patch.
>
> Regarding the names of the attributes: gah! I've left them at
> my mediocre attempts of names in order to hopefully get input on better
> names :-)
>
> I would welcome any comments, about the names, the approach, the attempt
> at documenting the intricacies of these attributes and anything.
>
> FWIW, this particular patch was regstrapped on x86-64-linux
> with trunk from a week ago (and sniff-tested on current trunk).
>
>
> Ciao,
> Michael.
>
> diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
> index 37cb5a0dcc4..92358f4ac41 100644
> --- a/gcc/config/i386/i386-options.cc
> +++ b/gcc/config/i386/i386-options.cc
> @@ -3244,6 +3244,16 @@ ix86_set_indirect_branch_type (tree fndecl)
> }
> }
>
> +unsigned
> +ix86_fntype_to_abi_id (const_tree fntype)
> +{
> + if (lookup_attribute ("nosseclobber", TYPE_ATTRIBUTES (fntype)))
> +return ABI_LESS_SSE;
> + if (lookup_attribute ("noanysseclobber", TYPE_ATT
[x86-64] RFC: Add nosse abi attribute
Hello,
the ELF psABI for x86-64 doesn't have any callee-saved SSE
registers (there were actual reasons for that, but those don't
matter anymore). This starts to hurt some uses, as it means that
as soon as you have a call (say to memmove/memcpy, even if
implicit as libcall) in a loop that manipulates floating point
or vector data you get saves/restores around those calls.
But in reality many functions can be written such that they only need
to clobber a subset of the 16 XMM registers (or do the save/restore
themself in the codepaths that needs them, hello memcpy again).
So we want to introduce a way to specify this, via an ABI attribute
that basically says "doesn't clobber the high XMM regs".
I've opted to do only the obvious: do something special only for
xmm8 to xmm15, without a way to specify the clobber set in more detail.
I think such half/half split is reasonable, and as I don't want to
change the argument passing anyway (whose regs are always clobbered)
there isn't that much wiggle room anyway.
I chose to make it possible to write function definitions with that
attribute with GCC adding the necessary callee save/restore code in
the xlogue itself. Carefully note that this is only possible for
the SSE2 registers, as other parts of them would need instructions
that are only optional. When a function doesn't contain calls to
unknown functions we can be a bit more lenient: we can make it so that
GCC simply doesn't touch xmm8-15 at all, then no save/restore is
necessary. If a function contains calls then GCC can't know which
parts of the XMM regset is clobbered by that, it may be parts
which don't even exist yet (say until avx2048 comes out), so we must
restrict ourself to only save/restore the SSE2 parts and then of course
can only claim to not clobber those parts.
To that end I introduce actually two related attributes (for naming
see below):
* nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
* noanysseclobber: claims (and ensures) that nothing of any of the
registers overlapping xmm8-15 is clobbered (not even future, as of
yet unknown, parts)
Ensuring the first is simple: potentially add saves/restore in xlogue
(e.g. when xmm8 is either used explicitely or implicitely by a call).
Ensuring the second comes with more: we must also ensure that no
functions are called that don't guarantee the same thing (in addition
to just removing all xmm8-15 parts alltogether from the available
regsters).
See also the added testcases for what I intended to support.
I chose to use the new target independend function-abi facility for
this. I need some adjustments in generic code:
* the "default_abi" is actually more like a "current" abi: it happily
changes its contents according to conditional_register_usage,
and other code assumes that such changes do propagate.
But if that conditonal_reg_usage is actually done because the current
function is of a different ABI, then we must not change default_abi.
* in insn_callee_abi we do look at a potential fndecl for a call
insn (only set when -fipa-ra), but doesn't work for calls through
pointers and (as said) is optional. So, also always look at the
called functions type (it's always recorded in the MEM_EXPR for
non-libcalls), before asking the target.
(The function-abi accessors working on trees were already doing that,
its just the RTL accessor that missed this)
Accordingly I also implement some more target hooks for function-abi.
With that it's possible to also move the other ABI-influencing code
of i386 to function-abi (ms_abi and friends). I have not done so for
this patch.
Regarding the names of the attributes: gah! I've left them at
my mediocre attempts of names in order to hopefully get input on better
names :-)
I would welcome any comments, about the names, the approach, the attempt
at documenting the intricacies of these attributes and anything.
FWIW, this particular patch was regstrapped on x86-64-linux
with trunk from a week ago (and sniff-tested on current trunk).
Ciao,
Michael.
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index 37cb5a0dcc4..92358f4ac41 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -3244,6 +3244,16 @@ ix86_set_indirect_branch_type (tree fndecl)
}
}
+unsigned
+ix86_fntype_to_abi_id (const_tree fntype)
+{
+ if (lookup_attribute ("nosseclobber", TYPE_ATTRIBUTES (fntype)))
+return ABI_LESS_SSE;
+ if (lookup_attribute ("noanysseclobber", TYPE_ATTRIBUTES (fntype)))
+return ABI_NO_SSE;
+ return ABI_DEFAULT;
+}
+
/* Establish appropriate back-end context for processing the function
FNDECL. The argument might be NULL to indicate processing at top
level, outside of any function scope. */
@@ -3311,6 +3321,12 @@ ix86_set_current_function (tree fndecl)
else
TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts ();
}
+
+ unsigned prev_abi_id = 0;
+ if (ix86_previous_fn
