rs6000: Fix issue in specifying PTImode as an attribute [PR106895]
Checks
Commit Message
Hi All,
The following patch has been bootstrapped and regtested on powerpc64le-linux.
When the user specifies PTImode as an attribute, it breaks. Created
a tree node to handle PTImode types. PTImode attribute helps in generating
even/odd register pairs on 128 bits.
2023-07-20 Jeevitha Palanisamy <jeevitha@linux.ibm.com>
gcc/
PR target/110411
* config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
to hold PTImode type.
* config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
for PTImode type.
gcc/testsuite/
PR target/106895
* gcc.target/powerpc/pr106895.c: New testcase.
Comments
Ping!
please review.
Thanks & Regards
Jeevitha
On 20/07/23 10:05 am, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> When the user specifies PTImode as an attribute, it breaks. Created
> a tree node to handle PTImode types. PTImode attribute helps in generating
> even/odd register pairs on 128 bits.
>
> 2023-07-20 Jeevitha Palanisamy <jeevitha@linux.ibm.com>
>
> gcc/
> PR target/110411
> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
> to hold PTImode type.
> * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
> for PTImode type.
>
> gcc/testsuite/
> PR target/106895
> * gcc.target/powerpc/pr106895.c: New testcase.
>
> diff --git a/gcc/config/rs6000/rs6000-builtin.cc b/gcc/config/rs6000/rs6000-builtin.cc
> index a8f291c6a72..ca00c3b0d4c 100644
> --- a/gcc/config/rs6000/rs6000-builtin.cc
> +++ b/gcc/config/rs6000/rs6000-builtin.cc
> @@ -756,6 +756,15 @@ rs6000_init_builtins (void)
> else
> ieee128_float_type_node = NULL_TREE;
>
> + /* PTImode to get even/odd register pairs. */
> + intPTI_type_internal_node = make_node(INTEGER_TYPE);
> + TYPE_PRECISION (intPTI_type_internal_node) = GET_MODE_BITSIZE (PTImode);
> + layout_type (intPTI_type_internal_node);
> + SET_TYPE_MODE (intPTI_type_internal_node, PTImode);
> + t = build_qualified_type (intPTI_type_internal_node, TYPE_QUAL_CONST);
> + lang_hooks.types.register_builtin_type (intPTI_type_internal_node,
> + "__int128pti");
> +
> /* Vector pair and vector quad support. */
> vector_pair_type_node = make_node (OPAQUE_TYPE);
> SET_TYPE_MODE (vector_pair_type_node, OOmode);
> diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
> index 3503614efbd..0456bf56d17 100644
> --- a/gcc/config/rs6000/rs6000.h
> +++ b/gcc/config/rs6000/rs6000.h
> @@ -2303,6 +2303,7 @@ enum rs6000_builtin_type_index
> RS6000_BTI_ptr_vector_quad,
> RS6000_BTI_ptr_long_long,
> RS6000_BTI_ptr_long_long_unsigned,
> + RS6000_BTI_PTI,
> RS6000_BTI_MAX
> };
>
> @@ -2347,6 +2348,7 @@ enum rs6000_builtin_type_index
> #define uintDI_type_internal_node (rs6000_builtin_types[RS6000_BTI_UINTDI])
> #define intTI_type_internal_node (rs6000_builtin_types[RS6000_BTI_INTTI])
> #define uintTI_type_internal_node (rs6000_builtin_types[RS6000_BTI_UINTTI])
> +#define intPTI_type_internal_node (rs6000_builtin_types[RS6000_BTI_PTI])
> #define float_type_internal_node (rs6000_builtin_types[RS6000_BTI_float])
> #define double_type_internal_node (rs6000_builtin_types[RS6000_BTI_double])
> #define long_double_type_internal_node (rs6000_builtin_types[RS6000_BTI_long_double])
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106895.c b/gcc/testsuite/gcc.target/powerpc/pr106895.c
> new file mode 100644
> index 00000000000..04630fe1df5
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106895.c
> @@ -0,0 +1,15 @@
> +/* PR target/106895 */
> +/* { dg-require-effective-target int128 } */
> +/* { dg-options "-O2" } */
> +
> +/* Verify the following generates even/odd register pairs. */
> +
> +typedef __int128 pti __attribute__((mode(PTI)));
> +
> +void
> +set128 (pti val, pti *mem)
> +{
> + asm("stq %1,%0" : "=m"(*mem) : "r"(val));
> +}
> +
> +/* { dg-final { scan-assembler "stq 10,0\\(5\\)" } } */
>
>
Hi,
on 2023/7/20 12:35, jeevitha via Gcc-patches wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> When the user specifies PTImode as an attribute, it breaks. Created
> a tree node to handle PTImode types. PTImode attribute helps in generating
> even/odd register pairs on 128 bits.
>
> 2023-07-20 Jeevitha Palanisamy <jeevitha@linux.ibm.com>
>
> gcc/
> PR target/110411
> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
> to hold PTImode type.
> * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
> for PTImode type.
>
> gcc/testsuite/
> PR target/106895
> * gcc.target/powerpc/pr106895.c: New testcase.
>
> diff --git a/gcc/config/rs6000/rs6000-builtin.cc b/gcc/config/rs6000/rs6000-builtin.cc
> index a8f291c6a72..ca00c3b0d4c 100644
> --- a/gcc/config/rs6000/rs6000-builtin.cc
> +++ b/gcc/config/rs6000/rs6000-builtin.cc
> @@ -756,6 +756,15 @@ rs6000_init_builtins (void)
> else
> ieee128_float_type_node = NULL_TREE;
>
> + /* PTImode to get even/odd register pairs. */
> + intPTI_type_internal_node = make_node(INTEGER_TYPE);
> + TYPE_PRECISION (intPTI_type_internal_node) = GET_MODE_BITSIZE (PTImode);
> + layout_type (intPTI_type_internal_node);
> + SET_TYPE_MODE (intPTI_type_internal_node, PTImode);
> + t = build_qualified_type (intPTI_type_internal_node, TYPE_QUAL_CONST);
> + lang_hooks.types.register_builtin_type (intPTI_type_internal_node,
> + "__int128pti");
IIUC, this builtin type registering makes this type expose to users, so
I wonder if we want to actually expose this type for users' uses.
If yes, we need to update the documentation (and not sure if the current
name is good enough); otherwise, I wonder if there is some existing
practice to declare a builtin type with a name which users can't actually
use and is just for shadowing a mode.
BR,
Kewen
> +
> /* Vector pair and vector quad support. */
> vector_pair_type_node = make_node (OPAQUE_TYPE);
> SET_TYPE_MODE (vector_pair_type_node, OOmode);
> diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
> index 3503614efbd..0456bf56d17 100644
> --- a/gcc/config/rs6000/rs6000.h
> +++ b/gcc/config/rs6000/rs6000.h
> @@ -2303,6 +2303,7 @@ enum rs6000_builtin_type_index
> RS6000_BTI_ptr_vector_quad,
> RS6000_BTI_ptr_long_long,
> RS6000_BTI_ptr_long_long_unsigned,
> + RS6000_BTI_PTI,
> RS6000_BTI_MAX
> };
>
> @@ -2347,6 +2348,7 @@ enum rs6000_builtin_type_index
> #define uintDI_type_internal_node (rs6000_builtin_types[RS6000_BTI_UINTDI])
> #define intTI_type_internal_node (rs6000_builtin_types[RS6000_BTI_INTTI])
> #define uintTI_type_internal_node (rs6000_builtin_types[RS6000_BTI_UINTTI])
> +#define intPTI_type_internal_node (rs6000_builtin_types[RS6000_BTI_PTI])
> #define float_type_internal_node (rs6000_builtin_types[RS6000_BTI_float])
> #define double_type_internal_node (rs6000_builtin_types[RS6000_BTI_double])
> #define long_double_type_internal_node (rs6000_builtin_types[RS6000_BTI_long_double])
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106895.c b/gcc/testsuite/gcc.target/powerpc/pr106895.c
> new file mode 100644
> index 00000000000..04630fe1df5
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106895.c
> @@ -0,0 +1,15 @@
> +/* PR target/106895 */
> +/* { dg-require-effective-target int128 } */
> +/* { dg-options "-O2" } */
> +
> +/* Verify the following generates even/odd register pairs. */
> +
> +typedef __int128 pti __attribute__((mode(PTI)));
> +
> +void
> +set128 (pti val, pti *mem)
> +{
> + asm("stq %1,%0" : "=m"(*mem) : "r"(val));
> +}
> +
> +/* { dg-final { scan-assembler "stq 10,0\\(5\\)" } } */
>
>
On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> When the user specifies PTImode as an attribute, it breaks. Created
> a tree node to handle PTImode types. PTImode attribute helps in generating
> even/odd register pairs on 128 bits.
>
> 2023-07-20 Jeevitha Palanisamy <jeevitha@linux.ibm.com>
>
> gcc/
> PR target/110411
> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
> to hold PTImode type.
> * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
> for PTImode type.
>
> gcc/testsuite/
> PR target/106895
> * gcc.target/powerpc/pr106895.c: New testcase.
It is good as far as it goes, but I suspect we will eventually need to extend
it. In particular, the reason people need PTImode is they need the even/odd
register layout. What you've done enables users to declare this value.
However, it is likely the users (kernel users mostly) will want to use it with
the atomic built-in functions that take 16 byte values. So I suspect we will
need to add overloads for those built-ins to allow either TImode and PTImode to
be used. Note, the PTImode built-in would bypass the TImode parts where they
convert a TImode into PTImode.
This is the reason PTImode was created in the first place. Due to the calling
sequence, TImode could be passed in odd/even (as well as even/odd) register
pairs, but the atomic insns and lq/stq need even/odd register pairs. But if
you are calling a built-in with PTImode, you don't have to convert it to
PTImode.
But then the next problem is what happens when people start using it. Do we
need to add all of the TImode insns (Add, subtract, and, ior, xor, shifts at
the very least)? These are the things I expect people might want to do for
memory accessed via atomic insns.
Then we get to the thorny problems of load/store on little endian systems, and
do we define the order of the two registers. Unfortunately, the lq/stq
instructions will load words in the opposite order as plq/pstq. I imagine the
kernel folk want to use lq/stq, but we may have to figure out exactly what they
want.
If we define any form of operation on PTImode, we likely need to define whether
register 0 has the high bits or low bits.
Sorry to be so negative, but those are a lot of the issues that might come up
as people use it.
On 8/24/23 12:35 PM, Michael Meissner wrote:
> On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
>> gcc/
>> PR target/110411
>> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
>> to hold PTImode type.
>> * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
>> for PTImode type.
>
> It is good as far as it goes, but I suspect we will eventually need to extend
> it. In particular, the reason people need PTImode is they need the even/odd
> register layout. What you've done enables users to declare this value.
Sure, it could be extended, but that is not what this patch is about.
It's purely to allow the kernel team access to the guaranteed even/odd
register layout for some inline asm code. Any extension would be a
follow-on patch to this.
On 8/9/23 3:48 AM, Kewen.Lin wrote:
> IIUC, this builtin type registering makes this type expose to users, so
> I wonder if we want to actually expose this type for users' uses.
> If yes, we need to update the documentation (and not sure if the current
> name is good enough); otherwise, I wonder if there is some existing
> practice to declare a builtin type with a name which users can't actually
> use and is just for shadowing a mode.
Segher, Mike, Jeevitha and I talked about the patch and Segher mentioned
that under some conditions, it's fine to keep the type undocumented.
Hopefully he'll weigh in on whether this particular patch is one of
those cases or not.
Peter
On Thu, Aug 24, 2023 at 09:19:51PM -0500, Peter Bergner wrote:
> On 8/24/23 12:35 PM, Michael Meissner wrote:
> > On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
> >> gcc/
> >> PR target/110411
> >> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
> >> to hold PTImode type.
> >> * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
> >> for PTImode type.
> >
> > It is good as far as it goes, but I suspect we will eventually need to extend
> > it. In particular, the reason people need PTImode is they need the even/odd
> > register layout. What you've done enables users to declare this value.
>
> Sure, it could be extended, but that is not what this patch is about.
> It's purely to allow the kernel team access to the guaranteed even/odd
> register layout for some inline asm code. Any extension would be a
> follow-on patch to this.
I think we need to get the intended users to try the compiler out, and see if
something else happens down the road that we didn't think of.
I tend to think of these things like the children's story "If you give a mouse
a cookie", which in turn leads to another thing and then another.
As I said, I would expect it would be temptimg to start use these types with
either 8 byte atomic built-ins, or do masks, etc.
In a way, it sort of reminds me of OOmode, where we have this opaque type to
load two vectors, but when you start trying to access the two separate
registers, you get all sorts of moves, because the compiler underneath the
covers doesn't really know it is two registers.
In general, I tend that people don't tend to have a full 128-bit integer, but
instead you have a structure with two fields, one is the lock and one is the
data. So you want to load things together (or do compare/swap, etc.) and then
you want to split the parts into 2 pieces, and then later, combine them back
into the PTImode container.
I really wish we had a constraint that matched the 2nd register in a multi-word
register (not an output operation, a constraint so that the register allocator
could know that you want to overlap a register).
Ping!
please review.
Thanks & Regards
Jeevitha
On 25/08/23 7:49 am, Peter Bergner wrote:
> On 8/24/23 12:35 PM, Michael Meissner wrote:
>> On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
>>> gcc/
>>> PR target/110411
>>> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
>>> to hold PTImode type.
>>> * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
>>> for PTImode type.
>>
>> It is good as far as it goes, but I suspect we will eventually need to extend
>> it. In particular, the reason people need PTImode is they need the even/odd
>> register layout. What you've done enables users to declare this value.
>
> Sure, it could be extended, but that is not what this patch is about.
> It's purely to allow the kernel team access to the guaranteed even/odd
> register layout for some inline asm code. Any extension would be a
> follow-on patch to this.
>
>
>
> On 8/9/23 3:48 AM, Kewen.Lin wrote:
>> IIUC, this builtin type registering makes this type expose to users, so
>> I wonder if we want to actually expose this type for users' uses.
>> If yes, we need to update the documentation (and not sure if the current
>> name is good enough); otherwise, I wonder if there is some existing
>> practice to declare a builtin type with a name which users can't actually
>> use and is just for shadowing a mode.
>
> Segher, Mike, Jeevitha and I talked about the patch and Segher mentioned
> that under some conditions, it's fine to keep the type undocumented.
> Hopefully he'll weigh in on whether this particular patch is one of
> those cases or not.
>
>
> Peter
Ping!
Please review
On 13/11/23 8:38 pm, jeevitha wrote:
> Ping!
>
> please review.
>
> Thanks & Regards
> Jeevitha
>
> On 25/08/23 7:49 am, Peter Bergner wrote:
>> On 8/24/23 12:35 PM, Michael Meissner wrote:
>>> On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
>>>> gcc/
>>>> PR target/110411
>>>> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
>>>> to hold PTImode type.
>>>> * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
>>>> for PTImode type.
>>>
>>> It is good as far as it goes, but I suspect we will eventually need to extend
>>> it. In particular, the reason people need PTImode is they need the even/odd
>>> register layout. What you've done enables users to declare this value.
>>
>> Sure, it could be extended, but that is not what this patch is about.
>> It's purely to allow the kernel team access to the guaranteed even/odd
>> register layout for some inline asm code. Any extension would be a
>> follow-on patch to this.
>>
>>
>>
>> On 8/9/23 3:48 AM, Kewen.Lin wrote:
>>> IIUC, this builtin type registering makes this type expose to users, so
>>> I wonder if we want to actually expose this type for users' uses.
>>> If yes, we need to update the documentation (and not sure if the current
>>> name is good enough);
Is the current name acceptable if we're not going to document the type?
>>
>> Segher, Mike, Jeevitha and I talked about the patch and Segher mentioned
>> that under some conditions, it's fine to keep the type undocumented.
>> Hopefully he'll weigh in on whether this particular patch is one of
>> those cases or not.
>>
>>
>> Peter
Thanks & Regards
Jeevitha
@@ -756,6 +756,15 @@ rs6000_init_builtins (void)
else
ieee128_float_type_node = NULL_TREE;
+ /* PTImode to get even/odd register pairs. */
+ intPTI_type_internal_node = make_node(INTEGER_TYPE);
+ TYPE_PRECISION (intPTI_type_internal_node) = GET_MODE_BITSIZE (PTImode);
+ layout_type (intPTI_type_internal_node);
+ SET_TYPE_MODE (intPTI_type_internal_node, PTImode);
+ t = build_qualified_type (intPTI_type_internal_node, TYPE_QUAL_CONST);
+ lang_hooks.types.register_builtin_type (intPTI_type_internal_node,
+ "__int128pti");
+
/* Vector pair and vector quad support. */
vector_pair_type_node = make_node (OPAQUE_TYPE);
SET_TYPE_MODE (vector_pair_type_node, OOmode);
@@ -2303,6 +2303,7 @@ enum rs6000_builtin_type_index
RS6000_BTI_ptr_vector_quad,
RS6000_BTI_ptr_long_long,
RS6000_BTI_ptr_long_long_unsigned,
+ RS6000_BTI_PTI,
RS6000_BTI_MAX
};
@@ -2347,6 +2348,7 @@ enum rs6000_builtin_type_index
#define uintDI_type_internal_node (rs6000_builtin_types[RS6000_BTI_UINTDI])
#define intTI_type_internal_node (rs6000_builtin_types[RS6000_BTI_INTTI])
#define uintTI_type_internal_node (rs6000_builtin_types[RS6000_BTI_UINTTI])
+#define intPTI_type_internal_node (rs6000_builtin_types[RS6000_BTI_PTI])
#define float_type_internal_node (rs6000_builtin_types[RS6000_BTI_float])
#define double_type_internal_node (rs6000_builtin_types[RS6000_BTI_double])
#define long_double_type_internal_node (rs6000_builtin_types[RS6000_BTI_long_double])
new file mode 100644
@@ -0,0 +1,15 @@
+/* PR target/106895 */
+/* { dg-require-effective-target int128 } */
+/* { dg-options "-O2" } */
+
+/* Verify the following generates even/odd register pairs. */
+
+typedef __int128 pti __attribute__((mode(PTI)));
+
+void
+set128 (pti val, pti *mem)
+{
+ asm("stq %1,%0" : "=m"(*mem) : "r"(val));
+}
+
+/* { dg-final { scan-assembler "stq 10,0\\(5\\)" } } */