On Sat, 2020-02-08 at 10:41 -0600, Segher Boessenkool wrote:
> On Fri, Feb 07, 2020 at 09:00:40AM -0700, Jeff Law wrote:
> > On Thu, 2020-02-06 at 07:56 -0600, Segher Boessenkool wrote:
> > > On Wed, Feb 05, 2020 at 11:48:23AM -0700, Jeff Law wrote:
> > > > Yea, it's closely related.  In your case you need to effectively ignore
> > > > the nop insn to get the optimization you want.  In mine that nop insn
> > > > causes an ICE.
> > > > 
> > > > I think we could take your cse bits + adding a !CALL_P separately from
> > > > the simplify-rtx stuff which Segher objected to.  THat'd likely solve
> > > > the ARM ICEs and take you a tiny step forward on optimizing that SVE
> > > > case.  Thoughts?
> > > 
> > > CSE should consistently keep track of what insns are no-op moves (in its
> > > definition, all passes have a slightly different definition of this),
> > > and use that everywhere consistently.
> > So does that mean you object to the cse.c portion of Richard's patch?
> 
> It's more a "what we need to do in the future" thing, it is stage 4 now,
> it is too big a change to do now.
I suspect you're referring to the simplify-rtx bits from his patch which I agree
are not appropriate for stage4.  The cse bits from that patch are are simple.

> 
> What patch?  The "34" patch?  https://gcc.gnu.org/r278411 .
> 
> I don't think each stanza of code should use it's own "noop-ness", no.
Richard's patch is actually better than mine in that regard as it handles mem and
reg nop moves in an indentical way.  I don't think refactoring the cse.c code is
advisable now though -- but I do want to fix the multiply-reported ICE on ARM and
Richard's cse changes are the cleanest way to do that that I can see.



> 
> I don't know if this patch makes matters worse or not.  It doesn't seem
> suitable for stage 4 though.  And Richard said the cse.c part breaks
> rs6000, if that is true, yes I do object ;-)
The rs6000 port breakage is trivial to fix.  In fact, I did so and ran it through
my tester, which includes ppc64le and ppc64 a slew of *-elf targets x86 native
and more.

Concretely I'm proposing the following patch to address 90275 and its duplicates.