Re: [PATCH, rtl-optimization]: Really fix PR 26449, [4.2/4.3 Regression] ICE in loop invariant motion

[Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>]

Hello,

> On 9/14/07, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
> 
> > > In this case, following (otherwise invariant) RTX will be rejected:
> > >
> > > (insn 147 146 148 21 loop-15.c:11 (set (subreg:V4SI (reg:V2DI 131) 0)
> > >         (vec_select:V4SI (vec_concat:V8SI (reg:V4SI 139)
> > >                 (reg:V4SI 134))
> > >             (parallel [
> > >                     (const_int 0 [0x0])
> > >                     (const_int 4 [0x4])
> > >                     (const_int 1 [0x1])
> > >                     (const_int 5 [0x5])
> > >                 ]))) 1270 {sse2_punpckldq} (nil))
> > >
> > > This insn is currenty marked as invariant, but since force_operand()
> > > will return NULL_RTX, your code will keep this insn (and whole insn
> > > chain) in the loop.
> >
> > so force_operand could try to emit the move insn, check whether it is valid,
> > and return the result if it is the case, before failing.
> 
> Please also note that for operands that are neither ARITHMETIC_P,
> neither RTX_UNARY, we also return the same RTX ('value') as was passed
> to force_operand, _not_ NULL_RTX. My patch just guides other
> unsupported RTX through the same path, avoiding ICE.
> 
> I'd say that the comment on top of function is wrong, this can be
> proved by sending i.e. RTX_EXTRA or RTX_TERNARY through force_operand.

well, I guess may mean that RTX_EXTRA or RTX_TERNARY are not supposed to
be passed to this function.  But overall, if you can give this function
some different semantics, that would be OK with me, as long as you are
able to specify what the function does/returns.

I do not like the proposed way of returning the expression unchanged,
though, as this way the function may return just about anything, 
thus becoming effectively useless.

Zdenek