This isn't precisely the same issue that we were originally tracking with 90275,
but it's closely related and we might as well stuff it in the same bucket.

This time instead of having a NOP copy insn that we can completely ignore and
ultimately remove, we have a NOP set within a multi-set PARALLEL.  It ultimately
triggers the same failure when the source of such a set is a hard register for
the same reasons as we've already noted in the BZ and patches-to-date.

For prior cases we've been able to mark the insn as a nop set and ignore it for
the rest of cse_insn, ultimately removing it.  That's not really an option here
as there are other sets that we have to preserve.

We might be able to fix this instance by splitting the multi-set insn, but I'm
not keen to introduce splitting into cse.  Furthermore, the target may not be
able to split the insn.  So I considered this is non-starter.

What I finally settled on was to use the existing do_not_record machinery to
ignore the nop set within the parallel (and only that set within the parallel). 
 

One might argue that we should always ignore a REG_UNUSED set.  But I rejected
that idea -- we could have cse-able divmod insns where the first had a 
REG_UNUSED
note for a destination, but the second did not.

One might also argue that we could have a nop set without a REG_UNUSED in a
multi-set parallel and thus we could trigger yet another insert_regs ICE at some
point.  I tend to think this is a possibility.  If we see this happen, we'll 
have
to revisit.

One might also argue that cse should, in general, be more tolerant of dead code
and nop sets.  I'd fully agree with that.  But I loathe the idea of revamping
that code and fear that we'd likely get it wrong along the way.  Certainly not
appropriate at the current time.

Bootstrapped and regression tested on a variety of *-linux-gnu targets 
(including
arm & aarch64).  Also regression tested on all the usual *-elf targets in the
tester.

Installing on the trunk,

jeff



commit 3737ccc424c56a2cecff202dd79f88d28850eeb2
Author: Jeff Law <l...@redhat.com>
Date:   Fri Apr 17 15:38:13 2020 -0600

    [committed] [PR rtl-optimization/90275] Another 90275 related cse.c fix
    
    This time instead of having a NOP copy insn that we can completely ignore 
and
    ultimately remove, we have a NOP set within a multi-set PARALLEL.  It 
triggers,
    the same failure when the source of such a set is a hard register for the 
same
    reasons as we've already noted in the BZ and patches-to-date.
    
    For prior cases we've been able to mark the insn as a nop set and ignore it 
for
    the rest of cse_insn, ultimately removing it.  That's not really an option 
here
    as there are other sets that we have to preserve.
    
    We might be able to fix this instance by splitting the multi-set insn, but 
I'm
    not keen to introduce splitting into cse.  Furthermore, the target may not 
be
    able to split the insn.  So I considered this is non-starter.
    
    What I finally settled on was to use the existing do_not_record machinery to
    ignore the nop set within the parallel (and only that set within the 
parallel).
    
    One might argue that we should always ignore a REG_UNUSED set.  But I 
rejected
    that idea -- we could have cse-able divmod insns where the first had a
    REG_UNUSED note for a destination, but the second did not.
    
    One might also argue that we could have a nop set without a REG_UNUSED in a
    multi-set parallel and thus we could trigger yet another insert_regs ICE at
    some point.  I tend to think this is a possibility.  If we see this happen,
    we'll have to revisit.
    
            PR rtl-optimization/90275
            * cse.c (cse_insn): Avoid recording nop sets in multi-set parallels
            when the destination has a REG_UNUSED note.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 93badc209ae..47f22327542 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-17  Jeff Law  <l...@redhat.com>
+
+       PR rtl-optimization/90275
+       * cse.c (cse_insn): Avoid recording nop sets in multi-set parallels
+       when the destination has a REG_UNUSED note.
+
 2020-04-17  Tobias Burnus  <tob...@codesourcery.com>
 
        PR middle-end/94635
diff --git a/gcc/cse.c b/gcc/cse.c
index f07bbdbebad..5aaba8d80e0 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -4715,8 +4715,20 @@ cse_insn (rtx_insn *insn)
 
       /* Compute SRC's hash code, and also notice if it
         should not be recorded at all.  In that case,
-        prevent any further processing of this assignment.  */
-      do_not_record = 0;
+        prevent any further processing of this assignment.
+
+        We set DO_NOT_RECORD if the destination has a REG_UNUSED note.
+        This avoids getting the source register into the tables, where it
+        may be invalidated later (via REG_QTY), then trigger an ICE upon
+        re-insertion.
+
+        This is only a problem in multi-set insns.  If it were a single
+        set the dead copy would have been removed.  If the RHS were anything
+        but a simple REG, then we won't call insert_regs and thus there's
+        no potential for triggering the ICE.  */
+      do_not_record = (REG_P (dest)
+                      && REG_P (src)
+                      && find_reg_note (insn, REG_UNUSED, dest));
       hash_arg_in_memory = 0;
 
       sets[i].src = src;
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 030550f1661..e5d0d92344c 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-17  Jeff Law  <l...@redhat.com>
+
+       PR rtl-optimization/90275
+       * gcc.c-torture/compile/pr90275-2.c: New test.
+
 2020-04-17  Patrick Palka  <ppa...@redhat.com>
 
        PR c++/94483
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr90275-2.c 
b/gcc/testsuite/gcc.c-torture/compile/pr90275-2.c
new file mode 100644
index 00000000000..9ebf7d9fd1a
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr90275-2.c
@@ -0,0 +1,12 @@
+
+void
+a() {
+  short *b;
+  short c;
+  long long *d = a;
+  for (;;) {
+    long long *e = a;
+    (*d *= *e - c) / *b ?: (*b = 0);
+  }
+}
+

Reply via email to