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.
