On Tue, 29 Jan 2013, Richard Biener wrote:

> So yes, handling BIT_FIELD_REF in the vectorizer looks like the correct
> way to do - but mind that you should constrain the BIT_FIELD_REFs you
> allow (I suppose in the end that's properly done by other part of the analysis).

Does that mean adding something like this to vectorizable_store? (and 
similarly to *_load)

if (VECTOR_TYPE_P (TREE_TYPE (scalar_dest)))
   return false;

Or maybe this?

if (TREE_CODE (scalar_dest) == BIT_FIELD_REF
     && !VECTOR_TYPE_P (TREE_TYPE (TREE_OPERAND (scalar_dest, 0)))
   return false;

Or checking that the type of the BIT_FIELD_REF is the element type of the 
vector type it accesses?

I am not sure what restrictions are needed.

> I suppose the data-ref analysis parts are not strictly required,

I removed the dr_analyze_indices part, which was indeed not necessary. The 
tree-vect-data-refs.c part is useless (the base object is not computed for 
SLP) but shouldn't hurt.

The current patch is attached (passed bootstrap+testsuite a week ago).
Are there some parts of this that could go in?


2013-03-30  Marc Glisse  <marc.glisse@inria.fr>

 	* tree-vect-stmts.c (vectorizable_store): Accept BIT_FIELD_REF.
 	(vectorizable_load): Likewise.
 	* tree-vect-slp.c (vect_build_slp_tree): Likewise.
 	* tree-vect-data-refs.c (vect_create_data_ref_ptr): Handle VECTOR_TYPE.
 	* tree-flow-inline.h (get_addr_base_and_unit_offset_1): Handle
 	BIT_FIELD_REF.

testsuite/
 	* gcc.dg/vect/bb-slp-31.c: New file.

-- 
Marc Glisse