[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 25 May 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |rguenth at gcc dot gnu.org
> 
> --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I guess 
> it depends on what exactly SCCVN uses the operand vectors 
> created/optimized by copy_reference_ops_from_ref/valueize_refs_1 for. If 
> it is used only for tracking what is the value of the reference (the 
> value stored into that piece of memory), or also for canonicalization of 
> references to certain more canonical form, or both.  If only the value 

It's only for tracking the value (and to get a canonical form for
its internal hash-tables and compare function).  I think this bug
may be related to PR63916.

> of the reference, then supposedly it would be nice to get far more 
> canonicalization in the references (e.g. turn (perhaps multiple nested) 
> COMPONENT_REFs into MEM_REFs with offset (except perhaps for bitfields, 
> perhaps even do something about ARRAY_REFs, so that say even: struct A { 
> float x, y; }; struct B { struct A u; }; void bar (struct A *);
> 
> float
> f2 (struct B *x, int y)
> {
>   struct A p;
>   p.x = 1.0f;
>   p.y = 2.0f;
>   char *z = (char *) x;
>   z += y * sizeof (struct B);
>   z += __builtin_offsetof (struct B, u.y);
>   x[y].u = p;
>   float f = *(float *) z;
>   bar (&p);
>   return f;
> }
> is handled).  But, supposedly it would be undesirable to canonicalize all the
> COMPONENT_REFs to the MEM_REFs (at least early on, e.g. for
> __builtin_object_size (, 1) purposes, or aliasing etc.).
> Richi, any thoughts on this?

On the f1 testcase it probably fails to look through the aggregate
copy in vn_reference_lookup_3.  I'll have a short look later.