On Tue, Jul 28, 2026 at 11:00 AM Andrew Stubbs <[email protected]> wrote: > > On 17/07/2026 18:19, Richard Biener wrote: > > > > > >> Am 17.07.2026 um 13:38 schrieb Andrew Stubbs <[email protected]>: > >> > >> 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? > > > > I mean you can write in your pass ‚turn MEM into a vec op‘ but how this is > > reflected into RTL is a detail that shouldn’t concern the pass itself (aka > > it might be an arbitrary complex but recognizable construct) > > > > The discussion seems to have run out of steam without producing a > conclusion.
Heh, sorry. It's still that I do not like (mem:<vector> ) much, I think it does not capture the GCN case well which the (parallel [(set (mem:<scalar> ...]) variant would. That doesn't solve your pattern explosion/typing problem, of course. Maybe that can be solved by parametrizing that (ick) (parallel_vec:<vector> [(set (mem:<scalar> (subreg:DI ...) ...)]) so basically have a parallel that implicitly enumerates operations on all vector lanes of a mode. The (parallel ..) bit implies it's unordered. I'm not exactly sure about the subreg part for the address - some magic needs to happen for the subreg offset of course. Would this be too restrictive? I think GCN can actually do few (two?) lanes as actual vector operation in an ALU, but I guess we're not modeling that. That said, I do not want to stand in the way of (mem:<vector> ..) when there's consensus this is the best general way to address this. > How can I proceed with this patch review? > > Thanks > > Andrew
