On Mon, Jul 20, 2026 at 10:50 PM Robin Dapp <[email protected]> wrote:
>
> > 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.
I'll note that for this very reason the autovectorizer assumes scatters are
left-to-right. As you say we cannot reasonably do a runtime check (OK,
there's separate ISA on x86 to detect conflicts, but we do not utilize that).
The md.texi docs for scatter_store roughly document that (we should
make the For each element index @var{i} more explicit I guess).
> 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
>
