Re: patch: relax VEC_SELECT assertion

[Jan Hubicka <jh at suse dot cz>]

> 
> On Oct 4, 2004, at 5:58 PM, Roger Sayle wrote:
> 
> >
> >On Mon, 4 Oct 2004, Stuart Hastings wrote:
> >>In simplify-rtx.c(simplify_binary_operation), an assertion of
> >>"VECTOR_MODE_P (GET_MODE (trueop0))" causes an unnecessary ICE.  This
> >>patch relaxes the assertion into a "if (non-vector-mode) then return
> >>0".  Given the returned zero, the caller (combiner) realizes the given
> >>RTX is illegal, and it eventually figures out something else that will
> >>work.
> >
> >This patch is working around the real problem.  You need to figure out
> >how an operand of non-vector type ended up as the first operand of the
> >vec_select.  A little digging reveals this instruction:
> >
> >(insn 31 30 33 0 (set (reg:V8QI 59 [ D.2583 ])
> >        (eq:V8QI (reg:V8QI 60 [ D.2580 ])
> >            (reg:V8QI 60 [ D.2580 ]))) 627 {eqv8qi3}
> >    (expr_list:REG_EQUAL (const_int 1 [0x1])
> >        (nil)))
> >
> >which has an incorrect REG_EQUAL note.
> 
> I agree this REG_EQUAL is incorrect and should be fixed, but it's moot; 
> here is an untested patch that removes the REG_EQUAL, yet the testcase 
> still fails:

This is likely becuase combine construct the wrong value itself too.
You should be able to fix this by inventing VECTOR_STORE_FLAG_VALUE
(mode) symmetric to what FLOAT_STORE_FLAG_VALUE does right now.

Honza