This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, rtl-optimization]: Really fix PR 26449, [4.2/4.3 Regression] ICE in loop invariant motion
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.
Uros.