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

bonzini paolo.bonzini@polimi.it
Mon Mar 22 15:58:00 GMT 2004


(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



More information about the Gcc-patches mailing list