[PATCH] [rs6000] Correct match pattern in pr56605.c

[PATCH] [rs6000] Correct match pattern in pr56605.c

[Alexandre Oliva]

Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590958.html

From: Haochen Gui <guihaoc@linux.ibm.com>

This patch corrects the match pattern in pr56605.c. The former pattern
is wrong and test case fails with GCC11. It should match following
insn on each subtarget after mode promotion is disabled. The patch
need to be backported to GCC11.

//gimple
_17 = (unsigned int) _20;
 prolog_loop_niters.4_23 = _17 & 3;

//rtl
(insn 19 18 20 2 (parallel [
            (set (reg:CC 208)
                (compare:CC (and:SI (subreg:SI (reg:DI 207) 0)
                        (const_int 3 [0x3]))
                    (const_int 0 [0])))
            (set (reg:SI 129 [ prolog_loop_niters.5 ])
                (and:SI (subreg:SI (reg:DI 207) 0)
                    (const_int 3 [0x3])))
        ]) 197 {*andsi3_imm_mask_dot2}

Rebased.  Regstrapped on ppc64-linux-gnu.  Also tested with
ppc64-vxworks7r2 (gcc-12), where it's also needed.  Ok to install?


for  gcc/testsuite/ChangeLog

	PR target/102146
	* gcc.target/powerpc/pr56605.c: Correct match pattern in
	combine pass.
---
 gcc/testsuite/gcc.target/powerpc/pr56605.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c b/gcc/testsuite/gcc.target/powerpc/pr56605.c
index 7695f87db6f66..651a88e3cc7f9 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
@@ -11,5 +11,4 @@ void foo (short* __restrict sb, int* __restrict ia)
     ia[i] = (int) sb[i];
 }
 
-/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:[SD]I) \((?:sub)?reg:[SD]I} 1 "combine" } } */
-
+/* { dg-final { scan-rtl-dump-times {\(compare:CC \(and:SI \(subreg:SI \(reg:DI} 1 "combine" } } */

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: [PATCH] [rs6000] Correct match pattern in pr56605.c

[Kewen.Lin]

Hi Alexandre and Haochen,

on 2023/3/25 16:42, Alexandre Oliva via Gcc-patches wrote:
> 
> Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590958.html
> 
> From: Haochen Gui <guihaoc@linux.ibm.com>
> 
> This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following
> insn on each subtarget after mode promotion is disabled. The patch
> need to be backported to GCC11.

Comment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146#c21 made me
feel that this test issue was just in branches, but this proposed patch
seems to say it still exists on trunk, could you confirm that?

BR,
Kewen

> 
> //gimple
> _17 = (unsigned int) _20;
>  prolog_loop_niters.4_23 = _17 & 3;
> 
> //rtl
> (insn 19 18 20 2 (parallel [
>             (set (reg:CC 208)
>                 (compare:CC (and:SI (subreg:SI (reg:DI 207) 0)
>                         (const_int 3 [0x3]))
>                     (const_int 0 [0])))
>             (set (reg:SI 129 [ prolog_loop_niters.5 ])
>                 (and:SI (subreg:SI (reg:DI 207) 0)
>                     (const_int 3 [0x3])))
>         ]) 197 {*andsi3_imm_mask_dot2}
> 
> Rebased.  Regstrapped on ppc64-linux-gnu.  Also tested with
> ppc64-vxworks7r2 (gcc-12), where it's also needed.  Ok to install?
> 
> 
> for  gcc/testsuite/ChangeLog
> 
> 	PR target/102146
> 	* gcc.target/powerpc/pr56605.c: Correct match pattern in
> 	combine pass.
> ---
>  gcc/testsuite/gcc.target/powerpc/pr56605.c |    3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c b/gcc/testsuite/gcc.target/powerpc/pr56605.c
> index 7695f87db6f66..651a88e3cc7f9 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
> @@ -11,5 +11,4 @@ void foo (short* __restrict sb, int* __restrict ia)
>      ia[i] = (int) sb[i];
>  }
>  
> -/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:[SD]I) \((?:sub)?reg:[SD]I} 1 "combine" } } */
> -
> +/* { dg-final { scan-rtl-dump-times {\(compare:CC \(and:SI \(subreg:SI \(reg:DI} 1 "combine" } } */

Re: [PATCH] [rs6000] Correct match pattern in pr56605.c

[HAO CHEN GUI]

Kewen,
  The case still fails with trunk.

FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC \\((?:and|zero_extend):(?:[SD]I) \\((?:sub)?reg:[SD]I" 1

                === gcc Summary ===

# of expected passes            1
# of unexpected failures        1

  With the trunk, it should match the pattern.
(compare:CC (and:SI (subreg:SI (reg:DI 207) 0)

Thanks
Gui Haochen


在 2023/3/27 15:41, Kewen.Lin 写道:
> Hi Alexandre and Haochen,
> 
> on 2023/3/25 16:42, Alexandre Oliva via Gcc-patches wrote:
>>
>> Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590958.html
>>
>> From: Haochen Gui <guihaoc@linux.ibm.com>
>>
>> This patch corrects the match pattern in pr56605.c. The former pattern
>> is wrong and test case fails with GCC11. It should match following
>> insn on each subtarget after mode promotion is disabled. The patch
>> need to be backported to GCC11.
> 
> Comment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146#c21 made me
> feel that this test issue was just in branches, but this proposed patch
> seems to say it still exists on trunk, could you confirm that?
> 
> BR,
> Kewen
> 
>>
>> //gimple
>> _17 = (unsigned int) _20;
>>  prolog_loop_niters.4_23 = _17 & 3;
>>
>> //rtl
>> (insn 19 18 20 2 (parallel [
>>             (set (reg:CC 208)
>>                 (compare:CC (and:SI (subreg:SI (reg:DI 207) 0)
>>                         (const_int 3 [0x3]))
>>                     (const_int 0 [0])))
>>             (set (reg:SI 129 [ prolog_loop_niters.5 ])
>>                 (and:SI (subreg:SI (reg:DI 207) 0)
>>                     (const_int 3 [0x3])))
>>         ]) 197 {*andsi3_imm_mask_dot2}
>>
>> Rebased.  Regstrapped on ppc64-linux-gnu.  Also tested with
>> ppc64-vxworks7r2 (gcc-12), where it's also needed.  Ok to install?
>>
>>
>> for  gcc/testsuite/ChangeLog
>>
>> 	PR target/102146
>> 	* gcc.target/powerpc/pr56605.c: Correct match pattern in
>> 	combine pass.
>> ---
>>  gcc/testsuite/gcc.target/powerpc/pr56605.c |    3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> index 7695f87db6f66..651a88e3cc7f9 100644
>> --- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> @@ -11,5 +11,4 @@ void foo (short* __restrict sb, int* __restrict ia)
>>      ia[i] = (int) sb[i];
>>  }
>>  
>> -/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:[SD]I) \((?:sub)?reg:[SD]I} 1 "combine" } } */
>> -
>> +/* { dg-final { scan-rtl-dump-times {\(compare:CC \(and:SI \(subreg:SI \(reg:DI} 1 "combine" } } */
> 

Re: [PATCH] [rs6000] Correct match pattern in pr56605.c

[Kewen.Lin]

Hi Haochen,

on 2023/3/27 17:46, HAO CHEN GUI wrote:
> Kewen,
>   The case still fails with trunk.
> 

OK, thanks for checking, the proposed patch can catch the expected pattern
accurately (excluding noises), so okay for trunk and branches, thanks!

BR,
Kewen

> FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC \\((?:and|zero_extend):(?:[SD]I) \\((?:sub)?reg:[SD]I" 1
> 
>                 === gcc Summary ===
> 
> # of expected passes            1
> # of unexpected failures        1
> 
>   With the trunk, it should match the pattern.
> (compare:CC (and:SI (subreg:SI (reg:DI 207) 0)

[PATCH, rs6000] Correct match pattern in pr56605.c

[HAO CHEN GUI]

Hi,
  This patch corrects the match pattern in pr56605.c. The former pattern
is wrong and test case fails with GCC11. It should match following insn on
each subtarget after mode promotion is disabled. The patch need to be
backported to GCC11.

//gimple
_17 = (unsigned int) _20;
 prolog_loop_niters.4_23 = _17 & 3;

//rtl
(insn 19 18 20 2 (parallel [
            (set (reg:CC 208)
                (compare:CC (and:SI (subreg:SI (reg:DI 207) 0)
                        (const_int 3 [0x3]))
                    (const_int 0 [0])))
            (set (reg:SI 129 [ prolog_loop_niters.5 ])
                (and:SI (subreg:SI (reg:DI 207) 0)
                    (const_int 3 [0x3])))
        ]) 197 {*andsi3_imm_mask_dot2}


  Bootstrapped and tested on powerpc64-linux BE/LE and AIX with no regressions.
Is this okay for trunk and GCC11? Any recommendations? Thanks a lot.

ChangeLog
2022-02-28 Haochen Gui <guihaoc@linux.ibm.com>

gcc/testsuite/
	PR target/102146
	* gcc.target/powerpc/pr56605.c: Correct match pattern in combine pass.


patch.diff
diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c b/gcc/testsuite/gcc.target/powerpc/pr56605.c
index fdedbfc573d..231d808aa99 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
@@ -11,5 +11,5 @@ void foo (short* __restrict sb, int* __restrict ia)
     ia[i] = (int) sb[i];
 }

-/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:DI) \((?:sub)?reg:[SD]I} 1 "combine" } } */
+/* { dg-final { scan-rtl-dump-times {\(compare:CC \(and:SI \(subreg:SI \(reg:DI} 1 "combine" } } */

Re: [PATCH, rs6000] Correct match pattern in pr56605.c

[will schmidt]

On Mon, 2022-02-28 at 11:17 +0800, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>   This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following insn on
> each subtarget after mode promotion is disabled. The patch need to be
> backported to GCC11.
> 

Hi,

I note This patch appears to (partially?) address the P1 [11 regression] pr.  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146


The issue makes reference to a different proposed patch 
in issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
titled  ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
proposed patch named
    rs6000: Disparage lfiwzx and similar

I can't address any of the background or history there.  :-)


> //gimple
> _17 = (unsigned int) _20;
>  prolog_loop_niters.4_23 = _17 & 3;
> 
> //rtl
> (insn 19 18 20 2 (parallel [
>             (set (reg:CC 208)
>                 (compare:CC (and:SI (subreg:SI (reg:DI 207) 0)
>                         (const_int 3 [0x3]))
>                     (const_int 0 [0])))
>             (set (reg:SI 129 [ prolog_loop_niters.5 ])
>                 (and:SI (subreg:SI (reg:DI 207) 0)
>                     (const_int 3 [0x3])))
>         ]) 197 {*andsi3_imm_mask_dot2}
> 
> 
>   Bootstrapped and tested on powerpc64-linux BE/LE and AIX with no regressions.
> Is this okay for trunk and GCC11? Any recommendations? Thanks a lot.
> 
> ChangeLog
> 2022-02-28 Haochen Gui <guihaoc@linux.ibm.com>
> 
> gcc/testsuite/
> 	PR target/102146
> 	* gcc.target/powerpc/pr56605.c: Correct match pattern in combine pass.
> 
> 
> patch.diff
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c b/gcc/testsuite/gcc.target/powerpc/pr56605.c
> index fdedbfc573d..231d808aa99 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
> @@ -11,5 +11,5 @@ void foo (short* __restrict sb, int* __restrict ia)
>      ia[i] = (int) sb[i];
>  }
> 
> -/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:DI) \((?:sub)?reg:[SD]I} 1 "combine" } } */
> +/* { dg-final { scan-rtl-dump-times {\(compare:CC \(and:SI \(subreg:SI \(reg:DI} 1 "combine" } } */


SO with the update, (i squint so this is an approximate handwave) this
drops the zero_extend and changes the destination type to be DI for the
scan-rtl.    This appears to match the rtl as mentioned in the patch
comments.


> 

Re: [PATCH, rs6000] Correct match pattern in pr56605.c

[HAO CHEN GUI]

Hi,

On 9/4/2022 上午 12:48, will schmidt wrote:
> On Mon, 2022-02-28 at 11:17 +0800, HAO CHEN GUI via Gcc-patches wrote:
>> Hi,
>>   This patch corrects the match pattern in pr56605.c. The former pattern
>> is wrong and test case fails with GCC11. It should match following insn on
>> each subtarget after mode promotion is disabled. The patch need to be
>> backported to GCC11.
>>
> 
> Hi,
> 
> I note This patch appears to (partially?) address the P1 [11 regression] pr.  
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146

There are two issues left in this PR. One is pr56605.c. My patch fixes it.
Another is prefix-no-update.c. The patch Segher proposed in 103197 could fix it.
Thanks.
> 
> 
> The issue makes reference to a different proposed patch 
> in issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
> titled  ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
> proposed patch named
>     rs6000: Disparage lfiwzx and similar
> 
> I can't address any of the background or history there.  :-)
> 
> 
>> //gimple
>> _17 = (unsigned int) _20;
>>  prolog_loop_niters.4_23 = _17 & 3;
>>
>> //rtl
>> (insn 19 18 20 2 (parallel [
>>             (set (reg:CC 208)
>>                 (compare:CC (and:SI (subreg:SI (reg:DI 207) 0)
>>                         (const_int 3 [0x3]))
>>                     (const_int 0 [0])))
>>             (set (reg:SI 129 [ prolog_loop_niters.5 ])
>>                 (and:SI (subreg:SI (reg:DI 207) 0)
>>                     (const_int 3 [0x3])))
>>         ]) 197 {*andsi3_imm_mask_dot2}
>>
>>
>>   Bootstrapped and tested on powerpc64-linux BE/LE and AIX with no regressions.
>> Is this okay for trunk and GCC11? Any recommendations? Thanks a lot.
>>
>> ChangeLog
>> 2022-02-28 Haochen Gui <guihaoc@linux.ibm.com>
>>
>> gcc/testsuite/
>> 	PR target/102146
>> 	* gcc.target/powerpc/pr56605.c: Correct match pattern in combine pass.
>>
>>
>> patch.diff
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> index fdedbfc573d..231d808aa99 100644
>> --- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> @@ -11,5 +11,5 @@ void foo (short* __restrict sb, int* __restrict ia)
>>      ia[i] = (int) sb[i];
>>  }
>>
>> -/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:DI) \((?:sub)?reg:[SD]I} 1 "combine" } } */
>> +/* { dg-final { scan-rtl-dump-times {\(compare:CC \(and:SI \(subreg:SI \(reg:DI} 1 "combine" } } */
> 
> 
> SO with the update, (i squint so this is an approximate handwave) this
> drops the zero_extend and changes the destination type to be DI for the
> scan-rtl.    This appears to match the rtl as mentioned in the patch
> comments.
> 
> 
>>
> 

Re: [PATCH, rs6000] Correct match pattern in pr56605.c

[Segher Boessenkool]

On Mon, Apr 11, 2022 at 10:47:53AM +0800, HAO CHEN GUI wrote:
> There are two issues left in this PR. One is pr56605.c. My patch fixes it.
> Another is prefix-no-update.c. The patch Segher proposed in 103197 could fix it.

So today all remaining problems will be fixed.  Thanks for shepherding
this PR!


Segher

Re: [PATCH, rs6000] Correct match pattern in pr56605.c

[Segher Boessenkool]

Hi!

On Mon, Feb 28, 2022 at 11:17:27AM +0800, HAO CHEN GUI wrote:
>   This patch corrects the match pattern in pr56605.c. The former pattern
> is wrong and test case fails with GCC11. It should match following insn on
> each subtarget after mode promotion is disabled. The patch need to be
> backported to GCC11.
> 
> //gimple
> _17 = (unsigned int) _20;
>  prolog_loop_niters.4_23 = _17 & 3;
> 
> //rtl
> (insn 19 18 20 2 (parallel [
>             (set (reg:CC 208)
>                 (compare:CC (and:SI (subreg:SI (reg:DI 207) 0)
>                         (const_int 3 [0x3]))
>                     (const_int 0 [0])))
>             (set (reg:SI 129 [ prolog_loop_niters.5 ])
>                 (and:SI (subreg:SI (reg:DI 207) 0)
>                     (const_int 3 [0x3])))
>         ]) 197 {*andsi3_imm_mask_dot2}
> 
> 
>   Bootstrapped and tested on powerpc64-linux BE/LE and AIX with no regressions.
> Is this okay for trunk and GCC11? Any recommendations? Thanks a lot.
> 
> ChangeLog
> 2022-02-28 Haochen Gui <guihaoc@linux.ibm.com>
> 
> gcc/testsuite/
> 	PR target/102146
> 	* gcc.target/powerpc/pr56605.c: Correct match pattern in combine pass.
> 
> 
> patch.diff
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c b/gcc/testsuite/gcc.target/powerpc/pr56605.c
> index fdedbfc573d..231d808aa99 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
> @@ -11,5 +11,5 @@ void foo (short* __restrict sb, int* __restrict ia)
>      ia[i] = (int) sb[i];
>  }
> 
> -/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:DI) \((?:sub)?reg:[SD]I} 1 "combine" } } */
> +/* { dg-final { scan-rtl-dump-times {\(compare:CC \(and:SI \(subreg:SI \(reg:DI} 1 "combine" } } */

The old pattern uses non-capturing braces here, which are required for
...-times to work correctly.  The zero_extend alternative is required as
well, as is making the subreg optional (we have an actual reg in one of
the cases currently).  What do you consider wrong about the old pattern,
what in the generated code is different from what you expect?

It works correctly on p7 etc. btw; where do you see it fail?  p10?


Segher

Re: [PATCH, rs6000] Correct match pattern in pr56605.c

[HAO CHEN GUI]

Hi,

On 9/4/2022 上午 3:36, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Feb 28, 2022 at 11:17:27AM +0800, HAO CHEN GUI wrote:
>>   This patch corrects the match pattern in pr56605.c. The former pattern
>> is wrong and test case fails with GCC11. It should match following insn on
>> each subtarget after mode promotion is disabled. The patch need to be
>> backported to GCC11.
>>
>> //gimple
>> _17 = (unsigned int) _20;
>>  prolog_loop_niters.4_23 = _17 & 3;
>>
>> //rtl
>> (insn 19 18 20 2 (parallel [
>>             (set (reg:CC 208)
>>                 (compare:CC (and:SI (subreg:SI (reg:DI 207) 0)
>>                         (const_int 3 [0x3]))
>>                     (const_int 0 [0])))
>>             (set (reg:SI 129 [ prolog_loop_niters.5 ])
>>                 (and:SI (subreg:SI (reg:DI 207) 0)
>>                     (const_int 3 [0x3])))
>>         ]) 197 {*andsi3_imm_mask_dot2}
>>
>>
>>   Bootstrapped and tested on powerpc64-linux BE/LE and AIX with no regressions.
>> Is this okay for trunk and GCC11? Any recommendations? Thanks a lot.
>>
>> ChangeLog
>> 2022-02-28 Haochen Gui <guihaoc@linux.ibm.com>
>>
>> gcc/testsuite/
>> 	PR target/102146
>> 	* gcc.target/powerpc/pr56605.c: Correct match pattern in combine pass.
>>
>>
>> patch.diff
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> index fdedbfc573d..231d808aa99 100644
>> --- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> @@ -11,5 +11,5 @@ void foo (short* __restrict sb, int* __restrict ia)
>>      ia[i] = (int) sb[i];
>>  }
>>
>> -/* { dg-final { scan-rtl-dump-times {\(compare:CC \((?:and|zero_extend):(?:DI) \((?:sub)?reg:[SD]I} 1 "combine" } } */
>> +/* { dg-final { scan-rtl-dump-times {\(compare:CC \(and:SI \(subreg:SI \(reg:DI} 1 "combine" } } */
> 
> The old pattern uses non-capturing braces here, which are required for
> ...-times to work correctly.  The zero_extend alternative is required as
> well, as is making the subreg optional (we have an actual reg in one of
> the cases currently).  What do you consider wrong about the old pattern,
> what in the generated code is different from what you expect?
> 
> It works correctly on p7 etc. btw; where do you see it fail?  p10?
> 
> 
I saw it failed with GCC11.

FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC \\((?:and|zero_extend):(?:DI) \\((?:sub)?reg:[SD]I" 1

On ppc64le with GCC11, it should match following insn.

(compare:CC (and:SI (subreg:SI (reg:DI 208) 0)

With GCC12, it should match following insn.

(compare:CC (and:SI (subreg:SI (reg:DI 207) 0)

With GCC12 the pattern actually matches:

(compare:CC (and:DI (subreg:DI (reg:SI 136 [ niters.6 ]) 0)

So GCC12 doesn't fail the case. But it actually match wrong insn.
There is no such insn in GCC11 combine dump. So GCC11 hits the problem.

Thanks.

> Segher