https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> --- > Am 23.11.2024 um 13:20 schrieb tnfchris at gcc dot gnu.org > <gcc-bugzi...@gcc.gnu.org>: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463 > > --- Comment #22 from Tamar Christina <tnfchris at gcc dot gnu.org> --- > Ok, so the problem with the ones on trunk isn't necessarily the > canonicalization itself but that our externals handling is a bit shallow. > > On externals we determine that we have no information on the DF and return > TOP. > This is because DR analysis doesn't try to handle externals since they're not > part of the loop. > > However all we need to know for complex numbers is whether the externals are > loaded from the same place and the order of them. > > concretely the loop pre-header is: > > <bb 2> [local count: 10737416]: > b$real_11 = REALPART_EXPR <b_15(D)>; > b$imag_10 = IMAGPART_EXPR <b_15(D)>; > _53 = -b$imag_10; > > and the loop body: > > <bb 3> [local count: 1063004408]: > ... > > _23 = REALPART_EXPR <*_5>; > _24 = IMAGPART_EXPR <*_5>; > _27 = _24 * _53; > _28 = _23 * _53; > > codegen before after: > > {_24, _23} * { _53, _53 } > > and after > > { _24, _24 } * { _53, b$real_11 } > > Before we were able to easily tell that the order for the multiply would be > IMAG, REAL. > In the after (GCC 15) case that information is there, but requires us to > follow > the externals. > > Richi what do you think about extending externals handling in linear_loads_p > to > follow all external ops and if they load from the same memref to figure out > the > "virtual lane permute"? Externs do not have a permute as we build them from scalars. So any permute can be trivially imposed on them - rather than TOP they should be BOTTOM. Of course there’s also no advantage of imposing a permute on them. > We can store the info in a new externals cache (to avoid re-walking externals > we already walked, as perm_cache stores slp nodes) and the permute for the > node in the perm_cache as we do for any cached lookups today? > > This would also fix the other tests Andrew added in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463#c4 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
