Re: [RFA][rtl-optimization/52714] Do not allow combine to create invalid RTL

[Jeff Law <law at redhat dot com>]

On 02/11/14 02:06, Eric Botcazou wrote:
> > I pondered changing the condition for swapping the insn order, but it
> > didn't seem worth it.  I doubt we see many 3->2 combinations where I3 is
> > a JUMP_INSN, the result turns into two simple sets and the insn swapping
> > code you wrote decides it needs to swap the insns.
>
> I didn't actually write it, just enhanced it recently, that's why I suggested
> to do the same here.  It's one line of code and we have an example of valid
> simplification at hand so I think we ought to do it.
>
> > It seems to me that as long as we're re-using the existing insns to
> > contain the simple sets that we have to ensure that they're INSNs, not
> > CALL_INSNs or JUMP_INSNs.
>
> I disagree, nullifying JUMP_INSNs by changing them to (set (pc) (pc)) is a
> standard method in the combiner.
So, the code has this structure

if (looks safe)
  emit in existing order
else if (reverse order looks safe)
  emit in reversed order
else
  undo_all


In this specific case, the existing order is never going to look safe 
because set1 uses (sp) as an input argument and use_crosses_set_p is 
very conservative when the value is the stack pointer on a PUSH_ROUNDING 
machine (such as the m68k)

So we could put the verification code that both I3 and I2 are INSNs in 
the else if (reverse order looks safe) clause.    That would mean for 
this testcase, we ultimately undo_all.  But I consider that reasonable 
given the only reason this instance bled into RTL land was -O1 instead 
of -O2 compilation.

I already know that variant works as it's what I had before I started 
thinking about what happens if we have a CALL_INSN as I2.

Jeff