diff options
| author | Kewen.Lin <linkw@gcc.gnu.org> | 2022-08-16 00:24:07 -0500 |
|---|---|---|
| committer | Kewen Lin <linkw@linux.ibm.com> | 2022-08-16 00:24:07 -0500 |
| commit | 9367e3a65f874dffc8f8a3b6760e77fd9ed67117 (patch) | |
| tree | 345d19f64aa9ef58719fb6f23abea26654e9a2ce /gcc/config | |
| parent | 5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98 (diff) | |
| download | gcc-9367e3a65f874dffc8f8a3b6760e77fd9ed67117.zip gcc-9367e3a65f874dffc8f8a3b6760e77fd9ed67117.tar.gz gcc-9367e3a65f874dffc8f8a3b6760e77fd9ed67117.tar.bz2 | |
rs6000: Adjust mov optabs for opaque modes [PR103353]
As PR103353 shows, we may want to continue to expand built-in
function __builtin_vsx_lxvp, even if we have already emitted
error messages about some missing required conditions. As
shown in that PR, without one explicit mov optab on OOmode
provided, it would call emit_move_insn recursively.
So this patch is to allow the mov pattern to be generated during
expanding phase if compiler has already seen errors.
PR target/103353
gcc/ChangeLog:
* config/rs6000/mma.md (define_expand movoo): Move TARGET_MMA condition
check to preparation statements and add handlings for !TARGET_MMA.
(define_expand movxo): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr103353.c: New test.
Diffstat (limited to 'gcc/config')
| -rw-r--r-- | gcc/config/rs6000/mma.md | 39 |
1 files changed, 33 insertions, 6 deletions
diff --git a/gcc/config/rs6000/mma.md b/gcc/config/rs6000/mma.md index a183b6a..032f426 100644 --- a/gcc/config/rs6000/mma.md +++ b/gcc/config/rs6000/mma.md @@ -268,10 +268,25 @@ (define_expand "movoo" [(set (match_operand:OO 0 "nonimmediate_operand") (match_operand:OO 1 "input_operand"))] - "TARGET_MMA" + "" { - rs6000_emit_move (operands[0], operands[1], OOmode); - DONE; + if (TARGET_MMA) + { + rs6000_emit_move (operands[0], operands[1], OOmode); + DONE; + } + else if (currently_expanding_to_rtl && seen_error ()) + { + /* PR103353 shows we may want to continue to expand the __builtin_vsx_lxvp + built-in function, even if we have already emitted error messages about + some missing required conditions. As shown in that PR, without one + explicit mov optab on OOmode provided, it would call emit_move_insn + recursively. So we allow this pattern to be generated when we are + expanding to RTL and have seen errors. It would not cause further ICEs + as the compilation would stop soon after expanding. */ + } + else + gcc_unreachable (); }) (define_insn_and_split "*movoo" @@ -300,10 +315,22 @@ (define_expand "movxo" [(set (match_operand:XO 0 "nonimmediate_operand") (match_operand:XO 1 "input_operand"))] - "TARGET_MMA" + "" { - rs6000_emit_move (operands[0], operands[1], XOmode); - DONE; + if (TARGET_MMA) + { + rs6000_emit_move (operands[0], operands[1], XOmode); + DONE; + } + else if (currently_expanding_to_rtl && seen_error ()) + { + /* PR103353 shows we may want to continue to expand the __builtin_vsx_lxvp + built-in function, even if we have already emitted error messages about + some missing required conditions. So do the same handlings for XOmode + as OOmode here. */ + } + else + gcc_unreachable (); }) (define_insn_and_split "*movxo" |