On 2/1/2022 7:45 AM, Robin Dapp wrote:
Hi,
this is a bugfix for aa8cfe785953a0e87d2472311e1260cd98c605c0 which
broke an or1k test case (PR104153) as well as SPARC bootstrap (PR104198).
cond_exec_get_condition () returns the jump condition directly and we
now it to the backend. The or1k backend modified the condition in-place
but this modification is not reverted when the sequence in question is
discarded. Therefore this patch copies the RTX instead of using it
directly.
The SPARC problem is due to the backend recreating the initial condition
when being passed a CC comparison. This causes the sequence
to read from an already overwritten condition operand. Generally, this
could also happen on other targets. The workaround is to always first
emit to a temporary. In a second run of noce_convert_multiple_1 we know
which sequences actually require the comparison and use no
temporaries if all sequences after the current one do not require it.
Before, I used reg_overlap_mentioned_p () to check the generated
instructions against the condition. The problem with this is that
reg_overlap... only handles a set of rtx_codes while a backend can
theoretically emit everything in an expander. Is reg_mentioned_p () the
"right thing" to do? Maybe it is overly conservative but as soon as we
have more than let's say three insns, we are unlikely to succeed anyway.
Bootstrapped and reg-tested on s390x, Power 9, x86 and SPARC.
Regards
Robin
--
PR 104198
PR 104153
gcc/ChangeLog:
* ifcvt.cc (noce_convert_multiple_sets_1): Copy rtx instead of
using it
directly. Rework comparison handling and always perform a
second pass.
gcc/testsuite/ChangeLog:
* gcc.dg/pr104198.c: New test.
Also note this fixed the or1k issues and it's been tested on a variety
of the embedded targets.
ifcvt-pr.patch
commit 68489d5729b4879bf2df540753fc7ea8ba1565a5
Author: Robin Dapp <rd...@linux.ibm.com>
Date: Mon Jan 24 10:28:05 2022 +0100
ifcvt: Fix PR104153 and PR104198.
This is a bugfix for aa8cfe785953a0e87d2472311e1260cd98c605c0 which
broke an or1k test case (PR104153) as well as SPARC bootstrap (PR104198).
cond_exec_get_condition () returns the jump condition directly and we now
pass it to the backend. The or1k backend modified the condition in-place
(other backends do that as well) but this modification is not reverted
when the sequence in question is discarded. Therefore we copy the RTX
instead of using it directly.
The SPARC problem is due to the SPARC backend recreating the initial
condition when being passed a CC comparison. This causes the sequence
to read from an already overwritten condition operand. Generally, this
could also happen on other targets. The workaround is to always first
emit to a temporary. In a second run of noce_convert_multiple_1 we know
which sequences actually require the comparison and will use no
temporaries if all sequences after the current one do not require it.
diff --git a/gcc/ifcvt.cc b/gcc/ifcvt.cc
index fe250d508e1..92c2b40a45a 100644
--- a/gcc/ifcvt.cc
+++ b/gcc/ifcvt.cc
@@ -3391,7 +3391,11 @@ noce_convert_multiple_sets_1 (struct noce_if_info
*if_info,
rtx cond = noce_get_condition (jump, &cond_earliest, false);
rtx cc_cmp = cond_exec_get_condition (jump);
+ if (cc_cmp)
+ cc_cmp = copy_rtx (cc_cmp);
rtx rev_cc_cmp = cond_exec_get_condition (jump, /* get_reversed */ true);
+ if (rev_cc_cmp)
+ rev_cc_cmp = copy_rtx (rev_cc_cmp);
rtx_insn *insn;
int count = 0;
@@ -3515,6 +3519,7 @@ noce_convert_multiple_sets_1 (struct noce_if_info
*if_info,
unsigned cost1 = 0, cost2 = 0;
rtx_insn *seq, *seq1, *seq2;
rtx temp_dest = NULL_RTX, temp_dest1 = NULL_RTX, temp_dest2 = NULL_RTX;
+ bool read_comparison = false;
seq1 = try_emit_cmove_seq (if_info, temp, cond,
new_val, old_val, need_cmov,
@@ -3524,10 +3529,38 @@ noce_convert_multiple_sets_1 (struct noce_if_info
*if_info,
as well. This allows the backend to emit a cmov directly without
creating an additional compare for each. If successful, costing
is easier and this sequence is usually preferred. */
- seq2 = try_emit_cmove_seq (if_info, target, cond,
+ seq2 = try_emit_cmove_seq (if_info, temp, cond,
Do you need to adjust anything now that this is emitting into TEMP
rather than TARGET?
jeff
