Re: [PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732]

[Kewen.Lin]

Hi Haochen,

on 2024/5/30 11:14, HAO CHEN GUI wrote:
> Hi Kewen,
> 
> 在 2024/5/29 13:26, Kewen.Lin 写道:
>> I can understand re-using "unordered" and "eq" will save some efforts than
>> doing with unspecs, but they are actually RTL codes instead of bits on the
>> specific hardware CR, a downside is that people who isn't aware of this
>> design point can have some misunderstanding when reading/checking the code
>> or dumping, from this perspective unspecs (with reasonable name) can be
>> more meaningful.  Normally adopting RTL code is better since they have the
>> chance to be considered (optimized) in generic pass/code, but it isn't the
>> case here as we just use the code itself but not be with the same semantic
>> (meaning).  Looking forward to others' opinions on this, if we want to adopt
>> "unordered" and "eq" like what this patch does, I think we should at least
>> emphasize such points in rs6000-modes.def.
> 
> Thanks so much for your comments. IMHO, the core is if we can re-define
> "unordered" or "eq" for certain CC mode on a specific target. If we can't or
> it's unsafe, we have to use the unspecs. In this case, I just want to define
> the code "unordered" on CCBCD as testing if the bit 3 is set on this CR field.

But my point is that "unordered" has its semantic, it looks a bit tricky to
adopt it on the result from BCD comparison when which only has "invalid" and
"overflow" other than normal ones, though I can understand that this patch
wants to use it to test bit 3 since for float comparison bit 3 is for
"unordered".  However, IMHO it would be more clear to have one unspec to test
bit 3 when bit 3 doesn't actually mean unordered result.

> Actually rs6000 already use "lt" code to test if bit 0 is set for vector
> compare instructions. The following expand is an example.

Yeah, but it doesn't mean it's the most sensible way to do this, IMHO it
suffers from the similar issue and can be improved as well.

> 
> (define_expand "vector_ae__p"
>   [(parallel
> [(set (reg:CC CR6_REGNO)
>   (unspec:CC [(ne:CC (match_operand:VI 1 "vlogical_operand")
>  (match_operand:VI 2 "vlogical_operand"))]
>UNSPEC_PREDICATE))
>  (set (match_dup 3)
>   (ne:VI (match_dup 1)
>  (match_dup 2)))])
>(set (match_operand:SI 0 "register_operand" "=r")
> (lt:SI (reg:CC CR6_REGNO)
>(const_int 0)))
>(set (match_dup 0)
> (xor:SI (match_dup 0)
> (const_int 1)))]
> 
> I think the "lt" on CC just doesn't mean it compares if CC value is less than 
> an
> integer. It just tests the "lt" bit (bit 0) is set or not on this CC.

But bit 0 doesn't mean for "lt" comparison result in this context any more.

BR,
Kewen

> 
>   Looking forward to your and Segher's further invaluable comments.
> 
> Thanks
> Gui Haochen

Re: [PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732]

[HAO CHEN GUI]

Hi Kewen,

在 2024/5/29 13:26, Kewen.Lin 写道:
> I can understand re-using "unordered" and "eq" will save some efforts than
> doing with unspecs, but they are actually RTL codes instead of bits on the
> specific hardware CR, a downside is that people who isn't aware of this
> design point can have some misunderstanding when reading/checking the code
> or dumping, from this perspective unspecs (with reasonable name) can be
> more meaningful.  Normally adopting RTL code is better since they have the
> chance to be considered (optimized) in generic pass/code, but it isn't the
> case here as we just use the code itself but not be with the same semantic
> (meaning).  Looking forward to others' opinions on this, if we want to adopt
> "unordered" and "eq" like what this patch does, I think we should at least
> emphasize such points in rs6000-modes.def.

Thanks so much for your comments. IMHO, the core is if we can re-define
"unordered" or "eq" for certain CC mode on a specific target. If we can't or
it's unsafe, we have to use the unspecs. In this case, I just want to define
the code "unordered" on CCBCD as testing if the bit 3 is set on this CR field.
Actually rs6000 already use "lt" code to test if bit 0 is set for vector
compare instructions. The following expand is an example.

(define_expand "vector_ae__p"
  [(parallel
[(set (reg:CC CR6_REGNO)
  (unspec:CC [(ne:CC (match_operand:VI 1 "vlogical_operand")
 (match_operand:VI 2 "vlogical_operand"))]
   UNSPEC_PREDICATE))
 (set (match_dup 3)
  (ne:VI (match_dup 1)
 (match_dup 2)))])
   (set (match_operand:SI 0 "register_operand" "=r")
(lt:SI (reg:CC CR6_REGNO)
   (const_int 0)))
   (set (match_dup 0)
(xor:SI (match_dup 0)
(const_int 1)))]

I think the "lt" on CC just doesn't mean it compares if CC value is less than an
integer. It just tests the "lt" bit (bit 0) is set or not on this CC.

  Looking forward to your and Segher's further invaluable comments.

Thanks
Gui Haochen

Re: [PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732]

[Kewen.Lin]

Hi,

on 2024/4/30 15:18, HAO CHEN GUI wrote:
> Hi,
>   It's the first patch of a series of patches optimizing CC modes on
> rs6000.
> 
>   bcd insns set all four bits of a CR field. But it has different single
> bit reverse behavior than CCFP's. The forth bit of bcd cr fields is used
> to indict overflow or invalid number. It's not a bit for unordered test.
> So the "le" test should be reversed to "gt" not "ungt". The "ge" test
> should be reversed to "lt" not "unlt". That's the root cause of PR100736
> and PR114732.
> 
>   This patch fixes the issue by adding a new type of CC mode - CCBCD for
> all bcd insns. Here a new setcc_rev pattern is added for ccbcd. It will
> be merged to a uniform pattern which is for all CC modes in sequential
> patch.

Thanks for doing this, adding one more CCmode for BCD specific looks
reasonable and make code more clear.

> 
>   The rtl code "unordered" is still used for testing overflow or
> invalid number. IMHO, the "unordered" on a CC mode can be considered as
> testing the forth bit of a CR field setting or not. The "eq" on a CC mode
> can be considered as testing the third bit setting or not. Thus we avoid
> creating lots of unspecs for the CR bit testing.

I can understand re-using "unordered" and "eq" will save some efforts than
doing with unspecs, but they are actually RTL codes instead of bits on the
specific hardware CR, a downside is that people who isn't aware of this
design point can have some misunderstanding when reading/checking the code
or dumping, from this perspective unspecs (with reasonable name) can be
more meaningful.  Normally adopting RTL code is better since they have the
chance to be considered (optimized) in generic pass/code, but it isn't the
case here as we just use the code itself but not be with the same semantic
(meaning).  Looking forward to others' opinions on this, if we want to adopt
"unordered" and "eq" like what this patch does, I think we should at least
emphasize such points in rs6000-modes.def.

> 
>   Bootstrapped and tested on powerpc64-linux BE and LE with no
> regressions. Is it OK for the trunk?

Some minor comments are inlined, Segher did a lot of work on CC, I'm looking
forward to his review on this patch series. :)

> 
> Thanks
> Gui Haochen
> 
> 
> ChangeLog
> rs6000: Add a new type of CC mode - CCBCD for bcd insns
> 
> gcc/
>   PR target/100736
>   PR target/114732
>   * config/rs6000/altivec.md (bcd_): Replace CCFP
>   with CCBCD.
>   (*bcd_test_): Likewise.
>   (*bcd_test2_): Likewise.
>   (bcd__): Likewise.
>   (*bcdinvalid_): Likewise.
>   (bcdinvalid_): Likewise.
>   (bcdshift_v16qi): Likewise.
>   (bcdmul10_v16qi): Likewise.
>   (bcddiv10_v16qi): Likewise.
>   (peephole for bcd_add/sub): Likewise.
>   * config/rs6000/predicates.md (branch_comparison_operator): Add CCBCD
>   and its supported comparison codes.
>   * config/rs6000/rs6000-modes.def (CC_MODE): Add CCBCD.
>   * config/rs6000/rs6000.cc (validate_condition_mode): Add CCBCD
>   assertion.
>   * config/rs6000/rs6000.md (CC_any): Add CCBCD.
>   (ccbcd_rev): New code iterator.
>   (*_cc): New insn and split pattern for CCBCD reverse
>   compare.
> 
> gcc/testsuite/
>   PR target/100736
>   PR target/114732
>   * gcc.target/powerpc/pr100736.c: New.
>   * gcc.target/powerpc/pr114732.c: New.
> 
> patch.diff
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index bb20441c096..9fa8cf89f61 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -4443,7 +4443,7 @@ (define_insn "bcd_"
> (match_operand:VBCD 2 "register_operand" "v")
> (match_operand:QI 3 "const_0_to_1_operand" "n")]
>UNSPEC_BCD_ADD_SUB))
> -   (clobber (reg:CCFP CR6_REGNO))]
> +   (clobber (reg:CCBCD CR6_REGNO))]
>"TARGET_P8_VECTOR"
>"bcd. %0,%1,%2,%3"
>[(set_attr "type" "vecsimple")])
> @@ -4454,8 +4454,8 @@ (define_insn "bcd_"
>  ;; probably should be one that can go in the VMX (Altivec) registers, so we
>  ;; can't use DDmode or DFmode.

Here is a paragraph of comments above:

;; Use a floating point type (V2DFmode) for the compare to set CR6 so that we
;; can use the unordered test for BCD nans and add/subtracts that overflow.  An
;; UNORDERED test on an integer type (like V1TImode) is not defined.  The type
;; probably should be one that can go in the VMX (Altivec) registers, so we
;; can't use DDmode or DFmode.

Is it still hold?  It's not obvious where is the code checking unordered test
should be on fp type (modes), if it still takes effect, "unspec" would help
to get rid of this restriction.  Otherwise, this comment should be updated
and we can drop this workaround with V2DF here.

>  (define_insn "*bcd_test_"
> -  [(set (reg:CCFP CR6_REGNO)
> - (compare:CCFP
> +  [(set (reg:CCBCD CR6_REGNO)
> + (compare:CCBCD
>(unspec:V2DF [(match_operand:VBCD 1 

Ping^2 [PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732]

[HAO CHEN GUI]

Hi,
  Gently ping them.

Thanks
Gui Haochen

在 2024/5/13 9:56, HAO CHEN GUI 写道:
> Hi,
>   Gently ping the series of patches.
> [PATCH-1, rs6000]Add a new type of CC mode - CCBCD for bcd insns [PR100736, 
> PR114732]
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650217.html
> [PATCH-2, rs6000] Add a new type of CC mode - CCLTEQ
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650218.html
> [PATCH-3, rs6000] Set CC mode of vector string isolate insns to CCEQ
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650219.html
> [PATCH-4, rs6000] Optimize single cc bit reverse implementation
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650220.html
> [PATCH-5, rs6000] Replace explicit CC bit reverse with common format
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650766.html
> [PATCH-6, rs6000] Split setcc to two insns after reload
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650856.html
> 
> Thanks
> Gui Haochen
> 
> 在 2024/4/30 15:18, HAO CHEN GUI 写道:
>> Hi,
>>   It's the first patch of a series of patches optimizing CC modes on
>> rs6000.
>>
>>   bcd insns set all four bits of a CR field. But it has different single
>> bit reverse behavior than CCFP's. The forth bit of bcd cr fields is used
>> to indict overflow or invalid number. It's not a bit for unordered test.
>> So the "le" test should be reversed to "gt" not "ungt". The "ge" test
>> should be reversed to "lt" not "unlt". That's the root cause of PR100736
>> and PR114732.
>>
>>   This patch fixes the issue by adding a new type of CC mode - CCBCD for
>> all bcd insns. Here a new setcc_rev pattern is added for ccbcd. It will
>> be merged to a uniform pattern which is for all CC modes in sequential
>> patch.
>>
>>   The rtl code "unordered" is still used for testing overflow or
>> invalid number. IMHO, the "unordered" on a CC mode can be considered as
>> testing the forth bit of a CR field setting or not. The "eq" on a CC mode
>> can be considered as testing the third bit setting or not. Thus we avoid
>> creating lots of unspecs for the CR bit testing.
>>
>>   Bootstrapped and tested on powerpc64-linux BE and LE with no
>> regressions. Is it OK for the trunk?
>>
>> Thanks
>> Gui Haochen
>>
>>
>> ChangeLog
>> rs6000: Add a new type of CC mode - CCBCD for bcd insns
>>
>> gcc/
>>  PR target/100736
>>  PR target/114732
>>  * config/rs6000/altivec.md (bcd_): Replace CCFP
>>  with CCBCD.
>>  (*bcd_test_): Likewise.
>>  (*bcd_test2_): Likewise.
>>  (bcd__): Likewise.
>>  (*bcdinvalid_): Likewise.
>>  (bcdinvalid_): Likewise.
>>  (bcdshift_v16qi): Likewise.
>>  (bcdmul10_v16qi): Likewise.
>>  (bcddiv10_v16qi): Likewise.
>>  (peephole for bcd_add/sub): Likewise.
>>  * config/rs6000/predicates.md (branch_comparison_operator): Add CCBCD
>>  and its supported comparison codes.
>>  * config/rs6000/rs6000-modes.def (CC_MODE): Add CCBCD.
>>  * config/rs6000/rs6000.cc (validate_condition_mode): Add CCBCD
>>  assertion.
>>  * config/rs6000/rs6000.md (CC_any): Add CCBCD.
>>  (ccbcd_rev): New code iterator.
>>  (*_cc): New insn and split pattern for CCBCD reverse
>>  compare.
>>
>> gcc/testsuite/
>>  PR target/100736
>>  PR target/114732
>>  * gcc.target/powerpc/pr100736.c: New.
>>  * gcc.target/powerpc/pr114732.c: New.
>>
>> patch.diff
>> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
>> index bb20441c096..9fa8cf89f61 100644
>> --- a/gcc/config/rs6000/altivec.md
>> +++ b/gcc/config/rs6000/altivec.md
>> @@ -4443,7 +4443,7 @@ (define_insn "bcd_"
>>(match_operand:VBCD 2 "register_operand" "v")
>>(match_operand:QI 3 "const_0_to_1_operand" "n")]
>>   UNSPEC_BCD_ADD_SUB))
>> -   (clobber (reg:CCFP CR6_REGNO))]
>> +   (clobber (reg:CCBCD CR6_REGNO))]
>>"TARGET_P8_VECTOR"
>>"bcd. %0,%1,%2,%3"
>>[(set_attr "type" "vecsimple")])
>> @@ -4454,8 +4454,8 @@ (define_insn "bcd_"
>>  ;; probably should be one that can go in the VMX (Altivec) registers, so we
>>  ;; can't use DDmode or DFmode.
>>  (define_insn "*bcd_test_"
>> -  [(set (reg:CCFP CR6_REGNO)
>> -(compare:CCFP
>> +  [(set (reg:CCBCD CR6_REGNO)
>> +(compare:CCBCD
>>   (unspec:V2DF [(match_operand:VBCD 1 "register_operand" "v")
>> (match_operand:VBCD 2 "register_operand" "v")
>> (match_operand:QI 3 "const_0_to_1_operand" "i")]
>> @@ -4472,8 +4472,8 @@ (define_insn "*bcd_test2_"
>>(match_operand:VBCD 2 "register_operand" "v")
>>(match_operand:QI 3 "const_0_to_1_operand" "i")]
>>   UNSPEC_BCD_ADD_SUB))
>> -   (set (reg:CCFP CR6_REGNO)
>> -(compare:CCFP
>> +   (set (reg:CCBCD CR6_REGNO)
>> +(compare:CCBCD
>>   (unspec:V2DF [(match_dup 1)
>> (match_dup 2)
>> (match_dup 3)]
>> @@ -4566,8 +4566,8 @@ (define_insn "vclrrb"
>> [(set_attr "type" 

Ping [PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732]

[HAO CHEN GUI]

Hi,
  Gently ping the series of patches.
[PATCH-1, rs6000]Add a new type of CC mode - CCBCD for bcd insns [PR100736, 
PR114732]
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650217.html
[PATCH-2, rs6000] Add a new type of CC mode - CCLTEQ
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650218.html
[PATCH-3, rs6000] Set CC mode of vector string isolate insns to CCEQ
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650219.html
[PATCH-4, rs6000] Optimize single cc bit reverse implementation
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650220.html
[PATCH-5, rs6000] Replace explicit CC bit reverse with common format
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650766.html
[PATCH-6, rs6000] Split setcc to two insns after reload
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650856.html

Thanks
Gui Haochen

在 2024/4/30 15:18, HAO CHEN GUI 写道:
> Hi,
>   It's the first patch of a series of patches optimizing CC modes on
> rs6000.
> 
>   bcd insns set all four bits of a CR field. But it has different single
> bit reverse behavior than CCFP's. The forth bit of bcd cr fields is used
> to indict overflow or invalid number. It's not a bit for unordered test.
> So the "le" test should be reversed to "gt" not "ungt". The "ge" test
> should be reversed to "lt" not "unlt". That's the root cause of PR100736
> and PR114732.
> 
>   This patch fixes the issue by adding a new type of CC mode - CCBCD for
> all bcd insns. Here a new setcc_rev pattern is added for ccbcd. It will
> be merged to a uniform pattern which is for all CC modes in sequential
> patch.
> 
>   The rtl code "unordered" is still used for testing overflow or
> invalid number. IMHO, the "unordered" on a CC mode can be considered as
> testing the forth bit of a CR field setting or not. The "eq" on a CC mode
> can be considered as testing the third bit setting or not. Thus we avoid
> creating lots of unspecs for the CR bit testing.
> 
>   Bootstrapped and tested on powerpc64-linux BE and LE with no
> regressions. Is it OK for the trunk?
> 
> Thanks
> Gui Haochen
> 
> 
> ChangeLog
> rs6000: Add a new type of CC mode - CCBCD for bcd insns
> 
> gcc/
>   PR target/100736
>   PR target/114732
>   * config/rs6000/altivec.md (bcd_): Replace CCFP
>   with CCBCD.
>   (*bcd_test_): Likewise.
>   (*bcd_test2_): Likewise.
>   (bcd__): Likewise.
>   (*bcdinvalid_): Likewise.
>   (bcdinvalid_): Likewise.
>   (bcdshift_v16qi): Likewise.
>   (bcdmul10_v16qi): Likewise.
>   (bcddiv10_v16qi): Likewise.
>   (peephole for bcd_add/sub): Likewise.
>   * config/rs6000/predicates.md (branch_comparison_operator): Add CCBCD
>   and its supported comparison codes.
>   * config/rs6000/rs6000-modes.def (CC_MODE): Add CCBCD.
>   * config/rs6000/rs6000.cc (validate_condition_mode): Add CCBCD
>   assertion.
>   * config/rs6000/rs6000.md (CC_any): Add CCBCD.
>   (ccbcd_rev): New code iterator.
>   (*_cc): New insn and split pattern for CCBCD reverse
>   compare.
> 
> gcc/testsuite/
>   PR target/100736
>   PR target/114732
>   * gcc.target/powerpc/pr100736.c: New.
>   * gcc.target/powerpc/pr114732.c: New.
> 
> patch.diff
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index bb20441c096..9fa8cf89f61 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -4443,7 +4443,7 @@ (define_insn "bcd_"
> (match_operand:VBCD 2 "register_operand" "v")
> (match_operand:QI 3 "const_0_to_1_operand" "n")]
>UNSPEC_BCD_ADD_SUB))
> -   (clobber (reg:CCFP CR6_REGNO))]
> +   (clobber (reg:CCBCD CR6_REGNO))]
>"TARGET_P8_VECTOR"
>"bcd. %0,%1,%2,%3"
>[(set_attr "type" "vecsimple")])
> @@ -4454,8 +4454,8 @@ (define_insn "bcd_"
>  ;; probably should be one that can go in the VMX (Altivec) registers, so we
>  ;; can't use DDmode or DFmode.
>  (define_insn "*bcd_test_"
> -  [(set (reg:CCFP CR6_REGNO)
> - (compare:CCFP
> +  [(set (reg:CCBCD CR6_REGNO)
> + (compare:CCBCD
>(unspec:V2DF [(match_operand:VBCD 1 "register_operand" "v")
>  (match_operand:VBCD 2 "register_operand" "v")
>  (match_operand:QI 3 "const_0_to_1_operand" "i")]
> @@ -4472,8 +4472,8 @@ (define_insn "*bcd_test2_"
> (match_operand:VBCD 2 "register_operand" "v")
> (match_operand:QI 3 "const_0_to_1_operand" "i")]
>UNSPEC_BCD_ADD_SUB))
> -   (set (reg:CCFP CR6_REGNO)
> - (compare:CCFP
> +   (set (reg:CCBCD CR6_REGNO)
> + (compare:CCBCD
>(unspec:V2DF [(match_dup 1)
>  (match_dup 2)
>  (match_dup 3)]
> @@ -4566,8 +4566,8 @@ (define_insn "vclrrb"
> [(set_attr "type" "vecsimple")])
> 
>  (define_expand "bcd__"
> -  [(parallel [(set (reg:CCFP CR6_REGNO)
> -(compare:CCFP
> +  [(parallel [(set (reg:CCBCD CR6_REGNO)
> + 

[PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732]

[HAO CHEN GUI]

Hi,
  It's the first patch of a series of patches optimizing CC modes on
rs6000.

  bcd insns set all four bits of a CR field. But it has different single
bit reverse behavior than CCFP's. The forth bit of bcd cr fields is used
to indict overflow or invalid number. It's not a bit for unordered test.
So the "le" test should be reversed to "gt" not "ungt". The "ge" test
should be reversed to "lt" not "unlt". That's the root cause of PR100736
and PR114732.

  This patch fixes the issue by adding a new type of CC mode - CCBCD for
all bcd insns. Here a new setcc_rev pattern is added for ccbcd. It will
be merged to a uniform pattern which is for all CC modes in sequential
patch.

  The rtl code "unordered" is still used for testing overflow or
invalid number. IMHO, the "unordered" on a CC mode can be considered as
testing the forth bit of a CR field setting or not. The "eq" on a CC mode
can be considered as testing the third bit setting or not. Thus we avoid
creating lots of unspecs for the CR bit testing.

  Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is it OK for the trunk?

Thanks
Gui Haochen


ChangeLog
rs6000: Add a new type of CC mode - CCBCD for bcd insns

gcc/
PR target/100736
PR target/114732
* config/rs6000/altivec.md (bcd_): Replace CCFP
with CCBCD.
(*bcd_test_): Likewise.
(*bcd_test2_): Likewise.
(bcd__): Likewise.
(*bcdinvalid_): Likewise.
(bcdinvalid_): Likewise.
(bcdshift_v16qi): Likewise.
(bcdmul10_v16qi): Likewise.
(bcddiv10_v16qi): Likewise.
(peephole for bcd_add/sub): Likewise.
* config/rs6000/predicates.md (branch_comparison_operator): Add CCBCD
and its supported comparison codes.
* config/rs6000/rs6000-modes.def (CC_MODE): Add CCBCD.
* config/rs6000/rs6000.cc (validate_condition_mode): Add CCBCD
assertion.
* config/rs6000/rs6000.md (CC_any): Add CCBCD.
(ccbcd_rev): New code iterator.
(*_cc): New insn and split pattern for CCBCD reverse
compare.

gcc/testsuite/
PR target/100736
PR target/114732
* gcc.target/powerpc/pr100736.c: New.
* gcc.target/powerpc/pr114732.c: New.

patch.diff
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index bb20441c096..9fa8cf89f61 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -4443,7 +4443,7 @@ (define_insn "bcd_"
  (match_operand:VBCD 2 "register_operand" "v")
  (match_operand:QI 3 "const_0_to_1_operand" "n")]
 UNSPEC_BCD_ADD_SUB))
-   (clobber (reg:CCFP CR6_REGNO))]
+   (clobber (reg:CCBCD CR6_REGNO))]
   "TARGET_P8_VECTOR"
   "bcd. %0,%1,%2,%3"
   [(set_attr "type" "vecsimple")])
@@ -4454,8 +4454,8 @@ (define_insn "bcd_"
 ;; probably should be one that can go in the VMX (Altivec) registers, so we
 ;; can't use DDmode or DFmode.
 (define_insn "*bcd_test_"
-  [(set (reg:CCFP CR6_REGNO)
-   (compare:CCFP
+  [(set (reg:CCBCD CR6_REGNO)
+   (compare:CCBCD
 (unspec:V2DF [(match_operand:VBCD 1 "register_operand" "v")
   (match_operand:VBCD 2 "register_operand" "v")
   (match_operand:QI 3 "const_0_to_1_operand" "i")]
@@ -4472,8 +4472,8 @@ (define_insn "*bcd_test2_"
  (match_operand:VBCD 2 "register_operand" "v")
  (match_operand:QI 3 "const_0_to_1_operand" "i")]
 UNSPEC_BCD_ADD_SUB))
-   (set (reg:CCFP CR6_REGNO)
-   (compare:CCFP
+   (set (reg:CCBCD CR6_REGNO)
+   (compare:CCBCD
 (unspec:V2DF [(match_dup 1)
   (match_dup 2)
   (match_dup 3)]
@@ -4566,8 +4566,8 @@ (define_insn "vclrrb"
[(set_attr "type" "vecsimple")])

 (define_expand "bcd__"
-  [(parallel [(set (reg:CCFP CR6_REGNO)
-  (compare:CCFP
+  [(parallel [(set (reg:CCBCD CR6_REGNO)
+  (compare:CCBCD
(unspec:V2DF [(match_operand:VBCD 1 "register_operand")
  (match_operand:VBCD 2 "register_operand")
  (match_operand:QI 3 "const_0_to_1_operand")]
@@ -4575,7 +4575,7 @@ (define_expand "bcd__"
(match_dup 4)))
  (clobber (match_scratch:VBCD 5))])
(set (match_operand:SI 0 "register_operand")
-   (BCD_TEST:SI (reg:CCFP CR6_REGNO)
+   (BCD_TEST:SI (reg:CCBCD CR6_REGNO)
 (const_int 0)))]
   "TARGET_P8_VECTOR"
 {
@@ -4583,8 +4583,8 @@ (define_expand "bcd__"
 })

 (define_insn "*bcdinvalid_"
-  [(set (reg:CCFP CR6_REGNO)
-   (compare:CCFP
+  [(set (reg:CCBCD CR6_REGNO)
+   (compare:CCBCD
 (unspec:V2DF [(match_operand:VBCD 1 "register_operand" "v")]
  UNSPEC_BCDSUB)
 (match_operand:V2DF 2 "zero_constant" "j")))
@@ -4594,14 +4594,14 @@ (define_insn "*bcdinvalid_"
   [(set_attr