public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH, rs6000] Call vector load/store with length expand only on 64-bit Power10 [PR96762]
@ 2023-08-29  2:50 HAO CHEN GUI
  2023-08-29  8:55 ` Kewen.Lin
  0 siblings, 1 reply; 4+ messages in thread
From: HAO CHEN GUI @ 2023-08-29  2:50 UTC (permalink / raw)
  To: gcc-patches; +Cc: Segher Boessenkool, David, Kewen.Lin, Peter Bergner

Hi,
  This patch adds "TARGET_64BIT" check when calling vector load/store
with length expand in expand_block_move. It matches the expand condition
of "lxvl" and "stxvl" defined in vsx.md.

  This patch fixes the ICE occurred with the test case on 32-bit Power10.

  Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.

Thanks
Gui Haochen


ChangeLog
rs6000: call vector load/store with length expand only on 64-bit Power10

gcc/
	PR target/96762
	* config/rs6000/rs6000-string.cc (expand_block_move): Call vector
	load/store with length expand only on 64-bit Power10.

gcc/testsuite/
	PR target/96762
	* gcc.target/powerpc/pr96762.c: New.


patch.diff
diff --git a/gcc/config/rs6000/rs6000-string.cc b/gcc/config/rs6000/rs6000-string.cc
index cd8ee8c..d1b48c2 100644
--- a/gcc/config/rs6000/rs6000-string.cc
+++ b/gcc/config/rs6000/rs6000-string.cc
@@ -2811,8 +2811,9 @@ expand_block_move (rtx operands[], bool might_overlap)
 	  gen_func.mov = gen_vsx_movv2di_64bit;
 	}
       else if (TARGET_BLOCK_OPS_UNALIGNED_VSX
-	       && TARGET_POWER10 && bytes < 16
-	       && orig_bytes > 16
+	       /* Only use lxvl/stxvl on 64bit POWER10.  */
+	       && TARGET_POWER10 && TARGET_64BIT
+	       && bytes < 16 && orig_bytes > 16
 	       && !(bytes == 1 || bytes == 2
 		    || bytes == 4 || bytes == 8)
 	       && (align >= 128 || !STRICT_ALIGNMENT))
diff --git a/gcc/testsuite/gcc.target/powerpc/pr96762.c b/gcc/testsuite/gcc.target/powerpc/pr96762.c
new file mode 100644
index 0000000..1145dd1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr96762.c
@@ -0,0 +1,11 @@
+/* { dg-do compile { target ilp32 } } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+extern void foo (char *);
+
+void
+bar (void)
+{
+  char zj[] = "XXXXXXXXXXXXXXXX";
+  foo (zj);
+}

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH, rs6000] Call vector load/store with length expand only on 64-bit Power10 [PR96762]
  2023-08-29  2:50 [PATCH, rs6000] Call vector load/store with length expand only on 64-bit Power10 [PR96762] HAO CHEN GUI
@ 2023-08-29  8:55 ` Kewen.Lin
  2023-08-31  5:47   ` HAO CHEN GUI
  0 siblings, 1 reply; 4+ messages in thread
From: Kewen.Lin @ 2023-08-29  8:55 UTC (permalink / raw)
  To: HAO CHEN GUI; +Cc: Segher Boessenkool, David, Peter Bergner, gcc-patches

Hi Haochen,

on 2023/8/29 10:50, HAO CHEN GUI wrote:
> Hi,
>   This patch adds "TARGET_64BIT" check when calling vector load/store
> with length expand in expand_block_move. It matches the expand condition
> of "lxvl" and "stxvl" defined in vsx.md.
> 
>   This patch fixes the ICE occurred with the test case on 32-bit Power10.
> 
>   Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
> 
> Thanks
> Gui Haochen
> 
> 
> ChangeLog
> rs6000: call vector load/store with length expand only on 64-bit Power10
> 
> gcc/
> 	PR target/96762
> 	* config/rs6000/rs6000-string.cc (expand_block_move): Call vector
> 	load/store with length expand only on 64-bit Power10.
> 
> gcc/testsuite/
> 	PR target/96762
> 	* gcc.target/powerpc/pr96762.c: New.
> 
> 
> patch.diff
> diff --git a/gcc/config/rs6000/rs6000-string.cc b/gcc/config/rs6000/rs6000-string.cc
> index cd8ee8c..d1b48c2 100644
> --- a/gcc/config/rs6000/rs6000-string.cc
> +++ b/gcc/config/rs6000/rs6000-string.cc
> @@ -2811,8 +2811,9 @@ expand_block_move (rtx operands[], bool might_overlap)
>  	  gen_func.mov = gen_vsx_movv2di_64bit;
>  	}
>        else if (TARGET_BLOCK_OPS_UNALIGNED_VSX
> -	       && TARGET_POWER10 && bytes < 16
> -	       && orig_bytes > 16
> +	       /* Only use lxvl/stxvl on 64bit POWER10.  */
> +	       && TARGET_POWER10 && TARGET_64BIT
> +	       && bytes < 16 && orig_bytes > 16
>  	       && !(bytes == 1 || bytes == 2
>  		    || bytes == 4 || bytes == 8)
>  	       && (align >= 128 || !STRICT_ALIGNMENT))

Nit: Since you touched this part of code, could you format it better as well, like:

      else if (TARGET_BLOCK_OPS_UNALIGNED_VSX
	       /* Only use lxvl/stxvl on 64bit POWER10.  */
	       && TARGET_POWER10
	       && TARGET_64BIT
	       && bytes < 16
	       && orig_bytes > 16
	       && !(bytes == 1
		    || bytes == 2
		    || bytes == 4
		    || bytes == 8)
	       && (align >= 128
		   || !STRICT_ALIGNMENT))


> diff --git a/gcc/testsuite/gcc.target/powerpc/pr96762.c b/gcc/testsuite/gcc.target/powerpc/pr96762.c
> new file mode 100644
> index 0000000..1145dd1
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr96762.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile { target ilp32 } } */

Nit: we can compile this on lp64, so you can remove the ilp32 restriction,
...

> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> +

... but add one comment line to note the initial purpose, like:

/* Verify there is no ICE on ilp32 env.  */

or similar.

Okay for trunk with these nits fixed, thanks!

BR,
Kewen

> +extern void foo (char *);
> +
> +void
> +bar (void)
> +{
> +  char zj[] = "XXXXXXXXXXXXXXXX";
> +  foo (zj);
> +}

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH, rs6000] Call vector load/store with length expand only on 64-bit Power10 [PR96762]
  2023-08-29  8:55 ` Kewen.Lin
@ 2023-08-31  5:47   ` HAO CHEN GUI
  2023-08-31  6:14     ` Kewen.Lin
  0 siblings, 1 reply; 4+ messages in thread
From: HAO CHEN GUI @ 2023-08-31  5:47 UTC (permalink / raw)
  To: Kewen.Lin; +Cc: Segher Boessenkool, David, Peter Bergner, gcc-patches

Kewen,
  I refined the patch according to your comments and it passed bootstrap
and regression test.

  I committed it as
https://gcc.gnu.org/g:946b8967b905257ac9f140225db744c9a6ab91be

Thanks
Gui Haochen

在 2023/8/29 16:55, Kewen.Lin 写道:
> Hi Haochen,
> 
> on 2023/8/29 10:50, HAO CHEN GUI wrote:
>> Hi,
>>   This patch adds "TARGET_64BIT" check when calling vector load/store
>> with length expand in expand_block_move. It matches the expand condition
>> of "lxvl" and "stxvl" defined in vsx.md.
>>
>>   This patch fixes the ICE occurred with the test case on 32-bit Power10.
>>
>>   Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
>>
>> Thanks
>> Gui Haochen
>>
>>
>> ChangeLog
>> rs6000: call vector load/store with length expand only on 64-bit Power10
>>
>> gcc/
>> 	PR target/96762
>> 	* config/rs6000/rs6000-string.cc (expand_block_move): Call vector
>> 	load/store with length expand only on 64-bit Power10.
>>
>> gcc/testsuite/
>> 	PR target/96762
>> 	* gcc.target/powerpc/pr96762.c: New.
>>
>>
>> patch.diff
>> diff --git a/gcc/config/rs6000/rs6000-string.cc b/gcc/config/rs6000/rs6000-string.cc
>> index cd8ee8c..d1b48c2 100644
>> --- a/gcc/config/rs6000/rs6000-string.cc
>> +++ b/gcc/config/rs6000/rs6000-string.cc
>> @@ -2811,8 +2811,9 @@ expand_block_move (rtx operands[], bool might_overlap)
>>  	  gen_func.mov = gen_vsx_movv2di_64bit;
>>  	}
>>        else if (TARGET_BLOCK_OPS_UNALIGNED_VSX
>> -	       && TARGET_POWER10 && bytes < 16
>> -	       && orig_bytes > 16
>> +	       /* Only use lxvl/stxvl on 64bit POWER10.  */
>> +	       && TARGET_POWER10 && TARGET_64BIT
>> +	       && bytes < 16 && orig_bytes > 16
>>  	       && !(bytes == 1 || bytes == 2
>>  		    || bytes == 4 || bytes == 8)
>>  	       && (align >= 128 || !STRICT_ALIGNMENT))
> 
> Nit: Since you touched this part of code, could you format it better as well, like:
> 
>       else if (TARGET_BLOCK_OPS_UNALIGNED_VSX
> 	       /* Only use lxvl/stxvl on 64bit POWER10.  */
> 	       && TARGET_POWER10
> 	       && TARGET_64BIT
> 	       && bytes < 16
> 	       && orig_bytes > 16
> 	       && !(bytes == 1
> 		    || bytes == 2
> 		    || bytes == 4
> 		    || bytes == 8)
> 	       && (align >= 128
> 		   || !STRICT_ALIGNMENT))
> 
> 
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr96762.c b/gcc/testsuite/gcc.target/powerpc/pr96762.c
>> new file mode 100644
>> index 0000000..1145dd1
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr96762.c
>> @@ -0,0 +1,11 @@
>> +/* { dg-do compile { target ilp32 } } */
> 
> Nit: we can compile this on lp64, so you can remove the ilp32 restriction,
> ...
> 
>> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
>> +
> 
> ... but add one comment line to note the initial purpose, like:
> 
> /* Verify there is no ICE on ilp32 env.  */
> 
> or similar.
> 
> Okay for trunk with these nits fixed, thanks!
> 
> BR,
> Kewen
> 
>> +extern void foo (char *);
>> +
>> +void
>> +bar (void)
>> +{
>> +  char zj[] = "XXXXXXXXXXXXXXXX";
>> +  foo (zj);
>> +}

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH, rs6000] Call vector load/store with length expand only on 64-bit Power10 [PR96762]
  2023-08-31  5:47   ` HAO CHEN GUI
@ 2023-08-31  6:14     ` Kewen.Lin
  0 siblings, 0 replies; 4+ messages in thread
From: Kewen.Lin @ 2023-08-31  6:14 UTC (permalink / raw)
  To: HAO CHEN GUI; +Cc: Segher Boessenkool, David, Peter Bergner, gcc-patches

on 2023/8/31 13:47, HAO CHEN GUI wrote:
> Kewen,
>   I refined the patch according to your comments and it passed bootstrap
> and regression test.
> 
>   I committed it as
> https://gcc.gnu.org/g:946b8967b905257ac9f140225db744c9a6ab91be

Thanks!  We want this to be backported, so it's also ok for backporting to all
affected branch releases after a week or so.

BR,
Kewen


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-08-31  6:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-29  2:50 [PATCH, rs6000] Call vector load/store with length expand only on 64-bit Power10 [PR96762] HAO CHEN GUI
2023-08-29  8:55 ` Kewen.Lin
2023-08-31  5:47   ` HAO CHEN GUI
2023-08-31  6:14     ` Kewen.Lin

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).