[RFC] [tree-ssa] Fix handling of BIT_FIELD_REFs and VECTOR_TYPEs

[bonzini <paolo dot bonzini at polimi dot it>]

(To Diego: sorry for the private mail, I sent by mistake)

> Hmm, get_expr_operands already handles BIT_FIELD_REFs.

Oops, my error.  I deleted the hunk that treated BIT_FIELD_REFs like 
other '1'-class tree codes.

>  Do you have a
> failing test case?  If we are not handling them like VOPs now, we should
> be failing tests. 

Unfortunately, I don't.  These (seems to me) bugs are exposed by my work 
to lower vectors into scalars if there is no instruction for that.  That 
code puts BIT_FIELD_REFs of VECTOR_TYPE variables in the left side of 
MODIFY_EXPRs, like

 v4qi a, b, c;
 ...
 T_3 = BIT_FIELD_REF (b_1, 0, 8);
 T_4 = BIT_FIELD_REF (c_2, 0, 8);
 T_5 = T_3 + T_4;
 BIT_FIELD_REF (a_6, 0, 8) = T_5;
 T_7 = BIT_FIELD_REF (b_1, 8, 8);
 T_8 = BIT_FIELD_REF (c_2, 8, 8);
 T_9 = T_7 + T_8;
 BIT_FIELD_REF (a_10, 8, 8) = T_9;
 ...

Without an "a_6 = VDEF (a_10)", dead-code elimination is obviously going 
to remove all the assignments but the last.  Something similar also 
happened without moving the BIT_FIELD_REF case in get_expr_operands; 
when I found this, I just went and adjusted it in every place where 
REALPART_EXPR and COMPONENT_REF were treated similarly.

Without my patch (which I planned to submit after the mainline merge), 
vectors are always treated like real ops at the tree level -- they are 
not at RTL level, where you have vec_set and vec_extract.  It is no 
problem for me to wait, so the patch can be considered just an RFC.

Paolo