RFC: [Patch, PR Bug 60818] - ICE in validate_condition_mode on powerpc*-linux-gnu* ]

[Alan Modra]

On Wed, Feb 17, 2016 at 06:31:45AM -0600, Segher Boessenkool wrote:
> > Corresponding content of "op" which causes the ICE:
> > gdb) p debug_rtx (op)
> > (gtu:SI (reg:CC 166)  ---------------------- (operator and mode doesn't match)
> >     (const_int 0 [0]))
> 
> That is invalid RTL for this target (should be CCUNS).  Invalid RTL
> should not be passed to recog.

Really??  combine does that all the time, when it asks "is this
instruction valid"!

> > (gdb) p debug_rtx (other_insn)
> > (insn 11 10 16 2 (set (reg:SI 165 [ D.2339+-3 ])
> >         (if_then_else:SI (ne (reg:CC 166)
> >                 (const_int 0 [0]))
> >             (reg:SI 168)
> >             (reg:SI 167))) test.c:7 317 {isel_unsigned_si}
> >      (expr_list:REG_DEAD (reg:SI 168)
> >         (expr_list:REG_DEAD (reg:SI 167)
> >             (expr_list:REG_DEAD (reg:CC 166)
> >                 (expr_list:REG_EQUAL (gtu:SI (reg:CC 166)
> >                         (const_int 0 [0]))
> >                     (nil))))))
> 
> The REG_EQUAL there is bad already.  Where does that come from?

Rohit explain that quite well already, I thought.  It's there due to
combine transforming a GTU to NE in another insn, which means the reg
mode changes to CCmode via rs6000.h:SELECT_CC_MODE.

You might argue that combine shouldn't create such a note, but whether
the note is valid or not depends on the target, doesn't it?  And the
usual way for combine to check validity of rtl is to form up an
instruction and pass that to recog.  Which is exactly what happens
later when combine tries to use the note and runs into the rs6000
backend assert.

It seems quite plain to me that this is primarily an rs6000 backend
problem, solved by the blindingly obvious patch I posted.  Whether you
want to do something in combine as well is a secondary problem.  The
rs6000 backend shouldn't assert on this rtl.

-- 
Alan Modra
Australia Development Lab, IBM