> 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)
Richard
>
> Andrew
