[Bug tree-optimization/114345] FRE missing knowledge of semantics of IFN loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345 --- Comment #6 from 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 --- > (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.
[Bug tree-optimization/114345] FRE missing knowledge of semantics of IFN loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345 --- Comment #5 from Tamar Christina --- (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?
[Bug tree-optimization/114345] FRE missing knowledge of semantics of IFN loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345 --- Comment #4 from Richard Biener --- 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.
[Bug tree-optimization/114345] FRE missing knowledge of semantics of IFN loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345 --- Comment #3 from Tamar Christina --- (In reply to Andrew Pinski from comment #2) > Oh VN does have some knowledge of MASK_STORE and LEN_STORE. Just not > LOAD_LANES . > > > See PR 106365 for MASK_STORE and LEN_STORE implementation. Shouldn't be hard > to add LOAD_LANES/STORE_LANES there ... Ah!, thanks for the pointer.
[Bug tree-optimization/114345] FRE missing knowledge of semantics of IFN loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106365 --- Comment #2 from Andrew Pinski --- Oh VN does have some knowledge of MASK_STORE and LEN_STORE. Just not LOAD_LANES . See PR 106365 for MASK_STORE and LEN_STORE implementation. Shouldn't be hard to add LOAD_LANES/STORE_LANES there ...
[Bug tree-optimization/114345] FRE missing knowledge of semantics of IFN loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-15 CC||pinskia at gcc dot gnu.org Status|UNCONFIRMED |NEW Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed. I thought there was already a bug recording this but I can't find it.
