* Re: [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS
[not found] <19289.124072908144101259@us-mta-160.us.mimecast.lan>
@ 2024-07-29 12:29 ` Jakub Jelinek
2024-07-29 12:52 ` Richard Biener
0 siblings, 1 reply; 9+ messages in thread
From: Jakub Jelinek @ 2024-07-29 12:29 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
On Mon, Jul 29, 2024 at 02:14:40PM +0200, Richard Biener wrote:
> The following adds a target hook to specify whether regs of MODE can be
> used to transfer bits. The hook is supposed to be used for value-numbering
> to decide whether a value loaded in such mode can be punned to another
> mode instead of re-loading the value in the other mode and for SRA to
> decide whether MODE is suitable as container holding a value to be
> used in different modes.
>
> * target.def (mode_can_transfer_bits): New target hook.
> * target.h (mode_can_transfer_bits): New function wrapping the
> hook and providing default behavior.
> * doc/tm.texi.in: Update.
> * doc/tm.texi: Re-generate.
> --- a/gcc/target.h
> +++ b/gcc/target.h
> @@ -312,6 +312,21 @@ estimated_poly_value (poly_int64 x,
> return targetm.estimated_poly_value (x, kind);
> }
>
> +/* Return true when MODE can be used to copy GET_MODE_BITSIZE bits
> + unchanged. */
> +
> +inline bool
> +mode_can_transfer_bits (machine_mode mode)
> +{
Shouldn't this start with
mode = GET_MODE_INNER (mode);
?
I mean say XCmode has similar problems as XFmode, or
V4SFmode as SFmode if i?86 -mno-sse.
Though, admittedly, with i?86 -msse2 -mfpmath=387 perhaps some vector modes
could work, which would argue for passing even vector modes to the hook.
Though the GET_MODE_BITSIZE != GET_MODE_PRECISION check then wants the inner
modes maybe.
> + if (mode == BLKmode)
> + return true;
> + if (maybe_ne (GET_MODE_BITSIZE (mode), GET_MODE_PRECISION (mode)))
> + return false;
> + if (targetm.mode_can_transfer_bits)
> + return targetm.mode_can_transfer_bits (mode);
> + return true;
> +}
> +
> #ifdef GCC_TM_H
>
> #ifndef CUMULATIVE_ARGS_MAGIC
> --
> 2.35.3
Jakub
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS
2024-07-29 12:29 ` [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS Jakub Jelinek
@ 2024-07-29 12:52 ` Richard Biener
2024-07-29 12:59 ` Jakub Jelinek
0 siblings, 1 reply; 9+ messages in thread
From: Richard Biener @ 2024-07-29 12:52 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:14:40PM +0200, Richard Biener wrote:
> > The following adds a target hook to specify whether regs of MODE can be
> > used to transfer bits. The hook is supposed to be used for value-numbering
> > to decide whether a value loaded in such mode can be punned to another
> > mode instead of re-loading the value in the other mode and for SRA to
> > decide whether MODE is suitable as container holding a value to be
> > used in different modes.
> >
> > * target.def (mode_can_transfer_bits): New target hook.
> > * target.h (mode_can_transfer_bits): New function wrapping the
> > hook and providing default behavior.
> > * doc/tm.texi.in: Update.
> > * doc/tm.texi: Re-generate.
>
>
> > --- a/gcc/target.h
> > +++ b/gcc/target.h
> > @@ -312,6 +312,21 @@ estimated_poly_value (poly_int64 x,
> > return targetm.estimated_poly_value (x, kind);
> > }
> >
> > +/* Return true when MODE can be used to copy GET_MODE_BITSIZE bits
> > + unchanged. */
> > +
> > +inline bool
> > +mode_can_transfer_bits (machine_mode mode)
> > +{
>
> Shouldn't this start with
> mode = GET_MODE_INNER (mode);
> ?
I specifically wanted to avoid this (at least for the purpose of the
hook).
> I mean say XCmode has similar problems as XFmode, or
> V4SFmode as SFmode if i?86 -mno-sse.
> Though, admittedly, with i?86 -msse2 -mfpmath=387 perhaps some vector modes
> could work, which would argue for passing even vector modes to the hook.
> Though the GET_MODE_BITSIZE != GET_MODE_PRECISION check then wants the inner
> modes maybe.
We do not support vector inner modes with padding. I didn't think of
XCmode - though precision is 160 here and size 192, so the padding
check should work there as well.
For vector I think the x86 backend ensures we never get x87 modes as
components. The middle-end will also not allow vector(1) float
with SFmode like it allows vector(1) int with SImode.
That said, the i386 implementation needs to handle XCmode, will
adjust.
Richard.
>
> > + if (mode == BLKmode)
> > + return true;
> > + if (maybe_ne (GET_MODE_BITSIZE (mode), GET_MODE_PRECISION (mode)))
> > + return false;
> > + if (targetm.mode_can_transfer_bits)
> > + return targetm.mode_can_transfer_bits (mode);
> > + return true;
> > +}
> > +
> > #ifdef GCC_TM_H
> >
> > #ifndef CUMULATIVE_ARGS_MAGIC
> > --
> > 2.35.3
>
> Jakub
>
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS
2024-07-29 12:52 ` Richard Biener
@ 2024-07-29 12:59 ` Jakub Jelinek
2024-07-29 13:26 ` Jakub Jelinek
2024-07-29 13:35 ` Richard Biener
0 siblings, 2 replies; 9+ messages in thread
From: Jakub Jelinek @ 2024-07-29 12:59 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > mode = GET_MODE_INNER (mode);
> > ?
>
> I specifically wanted to avoid this (at least for the purpose of the
> hook).
>
> > I mean say XCmode has similar problems as XFmode, or
> > V4SFmode as SFmode if i?86 -mno-sse.
> > Though, admittedly, with i?86 -msse2 -mfpmath=387 perhaps some vector modes
> > could work, which would argue for passing even vector modes to the hook.
> > Though the GET_MODE_BITSIZE != GET_MODE_PRECISION check then wants the inner
> > modes maybe.
>
> We do not support vector inner modes with padding. I didn't think of
> XCmode - though precision is 160 here and size 192, so the padding
> check should work there as well.
One thing is XCmode, another one is SCmode/DCmode/HCmode/BCmode without
-mfpmath=sse, there the target hook should say that it can't transfer bits.
For the vector V*[SDHB]Fmode it really depends on if it will be lowered to
scalar or vector moves.
And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
I think those should be considered as true by the hook, not false
because maybe_ne.
> For vector I think the x86 backend ensures we never get x87 modes as
> components. The middle-end will also not allow vector(1) float
It ensures there are no V*XFmode vectors. But whether say V*SFmode vectors
will result in vector moves which move everything safely or scalar which
would use x87 and be unsafe is unsure.
> with SFmode like it allows vector(1) int with SImode.
>
> That said, the i386 implementation needs to handle XCmode, will
> adjust.
Jakub
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS
2024-07-29 12:59 ` Jakub Jelinek
@ 2024-07-29 13:26 ` Jakub Jelinek
2024-07-29 13:35 ` Richard Biener
1 sibling, 0 replies; 9+ messages in thread
From: Jakub Jelinek @ 2024-07-29 13:26 UTC (permalink / raw)
To: Richard Biener, gcc-patches
On Mon, Jul 29, 2024 at 02:59:58PM +0200, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > > mode = GET_MODE_INNER (mode);
> > > ?
> >
> > I specifically wanted to avoid this (at least for the purpose of the
> > hook).
> >
> > > I mean say XCmode has similar problems as XFmode, or
> > > V4SFmode as SFmode if i?86 -mno-sse.
> > > Though, admittedly, with i?86 -msse2 -mfpmath=387 perhaps some vector modes
> > > could work, which would argue for passing even vector modes to the hook.
> > > Though the GET_MODE_BITSIZE != GET_MODE_PRECISION check then wants the inner
> > > modes maybe.
> >
> > We do not support vector inner modes with padding. I didn't think of
> > XCmode - though precision is 160 here and size 192, so the padding
> > check should work there as well.
>
> One thing is XCmode, another one is SCmode/DCmode/HCmode/BCmode without
> -mfpmath=sse, there the target hook should say that it can't transfer bits.
>
> For the vector V*[SDHB]Fmode it really depends on if it will be lowered to
> scalar or vector moves.
>
> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
> I think those should be considered as true by the hook, not false
> because maybe_ne.
Maybe the vector modes are ok on ia32, given -O2 -m32 -mno-sse
struct S { _Complex _Float16 a; __attribute__((vector_size (8 * sizeof (_Float16)))) _Float16 b; };
void
foo (struct S *p, struct S *q)
{
p->a = q->a;
q->b = p->b;
}
struct T { _Complex _Float32 a; __attribute__((vector_size (8 * sizeof (_Float32)))) _Float32 b; };
void
bar (struct T *p, struct T *q)
{
p->a = q->a;
q->b = p->b;
}
But SCmode/DCmode is not.
Jakub
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS
2024-07-29 12:59 ` Jakub Jelinek
2024-07-29 13:26 ` Jakub Jelinek
@ 2024-07-29 13:35 ` Richard Biener
2024-07-29 16:34 ` Richard Sandiford
1 sibling, 1 reply; 9+ messages in thread
From: Richard Biener @ 2024-07-29 13:35 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches, richard.sandiford
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > > mode = GET_MODE_INNER (mode);
> > > ?
> >
> > I specifically wanted to avoid this (at least for the purpose of the
> > hook).
> >
> > > I mean say XCmode has similar problems as XFmode, or
> > > V4SFmode as SFmode if i?86 -mno-sse.
> > > Though, admittedly, with i?86 -msse2 -mfpmath=387 perhaps some vector modes
> > > could work, which would argue for passing even vector modes to the hook.
> > > Though the GET_MODE_BITSIZE != GET_MODE_PRECISION check then wants the inner
> > > modes maybe.
> >
> > We do not support vector inner modes with padding. I didn't think of
> > XCmode - though precision is 160 here and size 192, so the padding
> > check should work there as well.
>
> One thing is XCmode, another one is SCmode/DCmode/HCmode/BCmode without
> -mfpmath=sse, there the target hook should say that it can't transfer bits.
I guess the adjusted hook doing
if (GET_MODE_CLASS (mode) == MODE_FLOAT
|| GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
switch (GET_MODE_INNER (mode))
{
case SFmode:
case DFmode:
return TARGET_SSE_MATH && !TARGET_MIX_SSE_I387;
default:
return false;
}
would cover that.
> For the vector V*[SDHB]Fmode it really depends on if it will be lowered to
> scalar or vector moves.
Hmm, indeed vector(4) float can get V4SFmode even without SSE enabled
since we use targetm.vector_mode_supported_any_target_p to decide
whether that mode is usable. So that might later get lowered to
x87 SFmode though the problematic load/store stmts are _not_ lowered
by vector lowering.
Indeed
typedef float v2sf __attribute__((vector_size(8)));
typedef int v2si __attribute__((vector_size(8)));
v2si v, v3;
v2sf v2;
void foo ()
{
v2sf x = *(v2sf *)&v;
v2si i = v;
v2 = x;
v3 = i;
}
gets optimized to
x_3 = MEM[(v2sf *)&v];
_7 = VIEW_CONVERT_EXPR<vector(2) int>(x_3);
v2 = x_3;
v3 = _7;
with -mno-sse even, but in the end the v2sf load prevails and gets
expanded via
movl v, %edx
movl v+4, %eax
same with double/long long.
So I _think_ this should not be a concern either. Actual float
operations remain float.
> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
> I think those should be considered as true by the hook, not false
> because maybe_ne.
I don't think relevant modes will have size/precision mismatches
and maybe_ne should work here. Richard?
> > For vector I think the x86 backend ensures we never get x87 modes as
> > components. The middle-end will also not allow vector(1) float
>
> It ensures there are no V*XFmode vectors. But whether say V*SFmode vectors
> will result in vector moves which move everything safely or scalar which
> would use x87 and be unsafe is unsure.
The experiment above shows it "works". I'm not sure to what extent
the x86 makes sure that SFmode moves never end up in the FP stack
on x86-64 - this is why it's up to the target hook to say what's safe
and what not.
Maybe the hook documentation needs to clarify with RTL specific
wording I am not aware of - it basically says whether a move through MODE
is preserving the bit pattern (so mem <- reg, reg <- mem but also reg <-
reg).
Richard.
> > with SFmode like it allows vector(1) int with SImode.
> >
> > That said, the i386 implementation needs to handle XCmode, will
> > adjust.
>
> Jakub
>
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS
2024-07-29 13:35 ` Richard Biener
@ 2024-07-29 16:34 ` Richard Sandiford
2024-07-30 7:14 ` Richard Biener
0 siblings, 1 reply; 9+ messages in thread
From: Richard Sandiford @ 2024-07-29 16:34 UTC (permalink / raw)
To: Richard Biener; +Cc: Jakub Jelinek, gcc-patches
Richard Biener <rguenther@suse.de> writes:
> On Mon, 29 Jul 2024, Jakub Jelinek wrote:
>> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
>> I think those should be considered as true by the hook, not false
>> because maybe_ne.
>
> I don't think relevant modes will have size/precision mismatches
> and maybe_ne should work here. Richard?
Yeah, I think that's true for AArch64 at least (not sure about RVV).
One wrinkle is that VNx16BI (every bit of a predicate) is technically
suitable for memcpy, even though it would be a bad choice performance-wise.
But VNx8BI (every even bit of a predicate) wouldn't, since the odd bits
are undefined on read.
Arguably, this means that VNx8BI has the wrong precision, but like you
say, we don't (AFAIK) support bitsize != precision for vector modes.
Instead, the information that there is only one meaningful bit per
boolean is represented by having an inner mode of BI. Both VNx16BI
and VNx8BI have an inner mode of BI, which means that VNx8BI's
precision is not equal the its nunits * its unit precision.
So I suppose:
maybe_ne (GET_MODE_BITSIZE (mode),
GET_MODE_UNIT_PRECISION (mode) * GET_MODE_NUNITS (mode))
would capture this.
Targets that want a vector bool mode with 2 meaningful bits per boolean
are expected to define a 2-bit scalar boolean mode and use that as the
inner mode. So I think the condition above would (correctly) continue
to allow those.
Thanks,
Richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS
2024-07-29 16:34 ` Richard Sandiford
@ 2024-07-30 7:14 ` Richard Biener
2024-07-30 8:46 ` Richard Sandiford
0 siblings, 1 reply; 9+ messages in thread
From: Richard Biener @ 2024-07-30 7:14 UTC (permalink / raw)
To: Richard Sandiford; +Cc: Jakub Jelinek, gcc-patches
On Mon, 29 Jul 2024, Richard Sandiford wrote:
> Richard Biener <rguenther@suse.de> writes:
> > On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> >> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
> >> I think those should be considered as true by the hook, not false
> >> because maybe_ne.
> >
> > I don't think relevant modes will have size/precision mismatches
> > and maybe_ne should work here. Richard?
>
> Yeah, I think that's true for AArch64 at least (not sure about RVV).
>
> One wrinkle is that VNx16BI (every bit of a predicate) is technically
> suitable for memcpy, even though it would be a bad choice performance-wise.
> But VNx8BI (every even bit of a predicate) wouldn't, since the odd bits
> are undefined on read.
>
> Arguably, this means that VNx8BI has the wrong precision, but like you
> say, we don't (AFAIK) support bitsize != precision for vector modes.
> Instead, the information that there is only one meaningful bit per
> boolean is represented by having an inner mode of BI. Both VNx16BI
> and VNx8BI have an inner mode of BI, which means that VNx8BI's
> precision is not equal the its nunits * its unit precision.
>
> So I suppose:
>
> maybe_ne (GET_MODE_BITSIZE (mode),
> GET_MODE_UNIT_PRECISION (mode) * GET_MODE_NUNITS (mode))
>
> would capture this.
OK, I'll adjust like this.
> Targets that want a vector bool mode with 2 meaningful bits per boolean
> are expected to define a 2-bit scalar boolean mode and use that as the
> inner mode. So I think the condition above would (correctly) continue
> to allow those.
Hmm, but I think SVE mask registers could be used to transfer bits?
I tried the following
typedef svint64_t v4dfm __attribute__((vector_mask));
void __GIMPLE(ssa) foo(void *p)
{
v4dfm _2;
__BB(2):
_2 = __MEM <v4dfm> ((v4dfm *)p);
__MEM <v4dfm> ((v4dfm *)p + 128) = _2;
return;
}
and it produces
ldr p15, [x0]
add x0, x0, 128
str p15, [x0]
exactly the same code as if using svint8_t which gets
signed-boolean:1 vs signed-boolean:8, so that mask producing
instructions get you undefined bits doesn't mean that
reg<->mem moves do the same since the predicate registers
don't know what modes they operate in?
It might of course be prohibitive to copy memory like this
and there might not be GPR <-> predicate reg moves.
But technically ... for SVE predicates there aren't even any
types less than 8 bits in size (as there are for GCN and AVX512).
Richard.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS
2024-07-30 7:14 ` Richard Biener
@ 2024-07-30 8:46 ` Richard Sandiford
0 siblings, 0 replies; 9+ messages in thread
From: Richard Sandiford @ 2024-07-30 8:46 UTC (permalink / raw)
To: Richard Biener; +Cc: Jakub Jelinek, gcc-patches
Richard Biener <rguenther@suse.de> writes:
> On Mon, 29 Jul 2024, Richard Sandiford wrote:
>
>> Richard Biener <rguenther@suse.de> writes:
>> > On Mon, 29 Jul 2024, Jakub Jelinek wrote:
>> >> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
>> >> I think those should be considered as true by the hook, not false
>> >> because maybe_ne.
>> >
>> > I don't think relevant modes will have size/precision mismatches
>> > and maybe_ne should work here. Richard?
>>
>> Yeah, I think that's true for AArch64 at least (not sure about RVV).
>>
>> One wrinkle is that VNx16BI (every bit of a predicate) is technically
>> suitable for memcpy, even though it would be a bad choice performance-wise.
>> But VNx8BI (every even bit of a predicate) wouldn't, since the odd bits
>> are undefined on read.
>>
>> Arguably, this means that VNx8BI has the wrong precision, but like you
>> say, we don't (AFAIK) support bitsize != precision for vector modes.
>> Instead, the information that there is only one meaningful bit per
>> boolean is represented by having an inner mode of BI. Both VNx16BI
>> and VNx8BI have an inner mode of BI, which means that VNx8BI's
>> precision is not equal the its nunits * its unit precision.
>>
>> So I suppose:
>>
>> maybe_ne (GET_MODE_BITSIZE (mode),
>> GET_MODE_UNIT_PRECISION (mode) * GET_MODE_NUNITS (mode))
>>
>> would capture this.
>
> OK, I'll adjust like this.
>
>> Targets that want a vector bool mode with 2 meaningful bits per boolean
>> are expected to define a 2-bit scalar boolean mode and use that as the
>> inner mode. So I think the condition above would (correctly) continue
>> to allow those.
>
> Hmm, but I think SVE mask registers could be used to transfer bits?
> I tried the following
>
> typedef svint64_t v4dfm __attribute__((vector_mask));
>
> void __GIMPLE(ssa) foo(void *p)
> {
> v4dfm _2;
>
> __BB(2):
> _2 = __MEM <v4dfm> ((v4dfm *)p);
> __MEM <v4dfm> ((v4dfm *)p + 128) = _2;
> return;
> }
>
> and it produces
>
> ldr p15, [x0]
> add x0, x0, 128
> str p15, [x0]
>
> exactly the same code as if using svint8_t which gets
> signed-boolean:1 vs signed-boolean:8, so that mask producing
> instructions get you undefined bits doesn't mean that
> reg<->mem moves do the same since the predicate registers
> don't know what modes they operate in?
Yes, in practice, VNx2BI is likely to produce the same load/store code
as VNx16BI. But when comparing VNx2BI for equality, say, only every
eighth bit matters. So if the optimisers were ultimately able to
determine which store feeds the VNx2BI load, there's a theoretical
possibility that they could do something that changes the other bits
of the value.
That's not very likely to happen. But it'd be a valid thing to do.
> It might of course be prohibitive to copy memory like this
> and there might not be GPR <-> predicate reg moves.
>
> But technically ... for SVE predicates there aren't even any
> types less than 8 bits in size (as there are for GCN and AVX512).
I guess its architected bits vs payload. The underlying registers
have 2N bytes for a 128N-bit VL, and so 2N bytes will be loaded by
LDR and stored by STR. But when GCC uses the registers as VNx2BI,
only 2N bits are payload, and so the optimisers only guarantee to
preserve those 2N bits.
Thanks,
Richard
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS
@ 2024-07-29 12:14 Richard Biener
0 siblings, 0 replies; 9+ messages in thread
From: Richard Biener @ 2024-07-29 12:14 UTC (permalink / raw)
To: gcc-patches; +Cc: Jakub Jelinek
The following adds a target hook to specify whether regs of MODE can be
used to transfer bits. The hook is supposed to be used for value-numbering
to decide whether a value loaded in such mode can be punned to another
mode instead of re-loading the value in the other mode and for SRA to
decide whether MODE is suitable as container holding a value to be
used in different modes.
* target.def (mode_can_transfer_bits): New target hook.
* target.h (mode_can_transfer_bits): New function wrapping the
hook and providing default behavior.
* doc/tm.texi.in: Update.
* doc/tm.texi: Re-generate.
---
gcc/doc/tm.texi | 6 ++++++
gcc/doc/tm.texi.in | 2 ++
gcc/target.def | 8 ++++++++
gcc/target.h | 15 +++++++++++++++
4 files changed, 31 insertions(+)
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index c7535d07f4d..fa53c23f1de 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -4545,6 +4545,12 @@ is either a declaration of type int or accessed by dereferencing
a pointer to int.
@end deftypefn
+@deftypefn {Target Hook} bool TARGET_MODE_CAN_TRANSFER_BITS (machine_mode @var{mode})
+Define this to return false if the mode @var{mode} cannot be used
+for memory copying. The default is to assume modes with the same
+precision as size are fine to be used.
+@end deftypefn
+
@deftypefn {Target Hook} machine_mode TARGET_TRANSLATE_MODE_ATTRIBUTE (machine_mode @var{mode})
Define this hook if during mode attribute processing, the port should
translate machine_mode @var{mode} to another mode. For example, rs6000's
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 64cea3b1eda..8af3f414505 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -3455,6 +3455,8 @@ stack.
@hook TARGET_REF_MAY_ALIAS_ERRNO
+@hook TARGET_MODE_CAN_TRANSFER_BITS
+
@hook TARGET_TRANSLATE_MODE_ATTRIBUTE
@hook TARGET_SCALAR_MODE_SUPPORTED_P
diff --git a/gcc/target.def b/gcc/target.def
index 3de1aad4c84..4356ef2f974 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -3363,6 +3363,14 @@ a pointer to int.",
bool, (ao_ref *ref),
default_ref_may_alias_errno)
+DEFHOOK
+(mode_can_transfer_bits,
+ "Define this to return false if the mode @var{mode} cannot be used\n\
+for memory copying. The default is to assume modes with the same\n\
+precision as size are fine to be used.",
+ bool, (machine_mode mode),
+ NULL)
+
/* Support for named address spaces. */
#undef HOOK_PREFIX
#define HOOK_PREFIX "TARGET_ADDR_SPACE_"
diff --git a/gcc/target.h b/gcc/target.h
index c1f99b97b86..c888ad39897 100644
--- a/gcc/target.h
+++ b/gcc/target.h
@@ -312,6 +312,21 @@ estimated_poly_value (poly_int64 x,
return targetm.estimated_poly_value (x, kind);
}
+/* Return true when MODE can be used to copy GET_MODE_BITSIZE bits
+ unchanged. */
+
+inline bool
+mode_can_transfer_bits (machine_mode mode)
+{
+ if (mode == BLKmode)
+ return true;
+ if (maybe_ne (GET_MODE_BITSIZE (mode), GET_MODE_PRECISION (mode)))
+ return false;
+ if (targetm.mode_can_transfer_bits)
+ return targetm.mode_can_transfer_bits (mode);
+ return true;
+}
+
#ifdef GCC_TM_H
#ifndef CUMULATIVE_ARGS_MAGIC
--
2.35.3
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2024-07-30 8:46 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <19289.124072908144101259@us-mta-160.us.mimecast.lan>
2024-07-29 12:29 ` [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS Jakub Jelinek
2024-07-29 12:52 ` Richard Biener
2024-07-29 12:59 ` Jakub Jelinek
2024-07-29 13:26 ` Jakub Jelinek
2024-07-29 13:35 ` Richard Biener
2024-07-29 16:34 ` Richard Sandiford
2024-07-30 7:14 ` Richard Biener
2024-07-30 8:46 ` Richard Sandiford
2024-07-29 12:14 Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).