https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 15 Mar 2024, tnfchris at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345 > > --- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #4) > > Well, the shuffling in .LOAD_LANES will be a bit awkward to do, but sure. > > We > > basically lack "constant folding" of .LOAD_LANES and similarly of course > > we can't see through .STORE_LANES of a constant when later folding a scalar > > load from the same memory. > > I guess it becomes harder with the 3 and 4 lane ones, but the 2 lanes one is > just a single VEC_PERM_EXPR no? It's all about constant folding and thus "shuffling" properly. But if you consider that the vector type might be punned a later "long" load of a .STORE_LANES with "int" lanes it will get interesting to now follow non-consecutive bits... (read: that's not implemented). That said, some careful set of testcases should accompany support for .LOAD_LANES and .STORE_LANES handling in VN. I suppose it should be possible to leverage the GIMPLE FE for this.
