On 17/07/2026 11:48, Richard Biener wrote:
On Fri, Jul 17, 2026 at 12:13 PM Andrew Stubbs <[email protected]> wrote:
On 17/07/2026 09:13, Richard Biener 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?
This is intended to be an enabling technology for my real project, in
which I want to transform scalar operations into vector operations in
the backend, and the special casing for memory accesses was getting out
of hand. By expressing (unmasked) vector operations identically to the
scalar equivalent I can simplify things greatly, and the other compiler
passes can do (some of) their special MEM handling as they normally would.
I see. I guess you ruled out a
([parallel
(set (mem:<scalar> ...) (...))
(set (mem:<scalar> ...) (...))])
I would need this insn for V2, V4, V8, V16, V32, and V64. And probably
SI/SF, DI/DF, and TI variants of each of those too (maybe QI and HI also).
It would be very verbose, and what would the constraints even look like?
Not to mention it's right back to the special-case conversions I was
trying to avoid in the first place.
etc. with vector extracts for the address. At least for "transform scalar ops
to vectors" the actual representation of the MEM could be a black box
as long as you
have addresses in vectors (which is possible already).
I'm not really sure what this means. Can you give an example, please?
Andrew
