> On Wed, Jul 8, 2026 at 4:48 PM Andrew Stubbs <[email protected]> wrote: >> >> Hi all, >> >> This patch series implements the "MEMs with address vectors" feature >> that I want to use in AMD GCN, and have previously discussed on gcc@. >> The motivation is to simplify a new back-end optimization pass I'm >> working on and plan to post in the coming weeks. >> >> The first patch, in this series, is the middle-end enablement and >> documentation changes. >> >> The second patch converts the amdgcn back-end to use the new scheme, >> without adding any real new features. It depends on the >> INSN_BASE_REG_CLASS patch I posted last week (still in review) to run >> correctly. >> >> The third and final patch demonstrates how I can use the new MEM to >> extend my machine description without writing whole new insns for the >> vector modes, just for them to evaluate to the same assembler code in >> the end. >> >> I have not yet finished testing the patches, so these might not be quite >> the final form, but I'm not expecting big changes to the middle-end >> portion. (I can self-approve the amdgcn parts, once the other is >> committed, but comments are welcome.) >> >> OK for mainline? (Pending test results.) > > I think this exposes what GCN does in a natural way. I'm not sure > the advantage (exposing former gather/scatter as move) is not > also its disadvantage (moves are special!), and I somewhat question > the benefit over using some UNSPEC for this. For example I would > assume that you side-step RTL alias/dependence analysis, meaning these > are barriers for optimization and scheduling? > > The proposed semantics (overlap has undefined behavior) does not > match up with usual vector ISA scatter semantics (left-to-right), so > the representation isn't universally useable (if we solve the masking > issue).
I just realized that we use the unordered flavor for scatters in RVV... Right now, the only reasonable thing a mem:<V> can represent is unordered accesses? And, as established in the RFC thread, we definitely need at least a non-overlap flag if it is supposed to be useful for scatter? And how would we even determine non-overlap? I don't see that we even can, apart from the stride-0 case. So we would still need the hardware to operate left-to-right and mem:<V> would effectively become an unspec again. On top, IIRC we assume somewhere that for mem:<mode> GET_MODE_SIZE (<mode>) is the size of the accessed memory. I guess (mem:BLK (reg:V16SI)) was already discussed and considered bad/unwanted/worst of both worlds? -- Regards Robin
