Vector pointer modes

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Vector pointer modes

Andrew Stubbs-4
Hi all,

I'm in the process of trying to update our AMD GCN port from GCC 7 to
GCC 8+, but I've hit a problem ...

It seems there's a new assumption that pointers and addresses will be
scalar, but GCN load instructions require vectors of pointers.
Basically, machine_mode has been replaced with scalar_int_machine mode
in many places, and we were relying on vector modes being allowed.

The changes are all coming from the Richard Sandiford's SVE patches.

Is there a new way of dealing with vectors of pointers?

Thanks

Andrew
Reply | Threaded
Open this post in threaded view
|

Re: Vector pointer modes

Richard Biener-2
On May 16, 2018 6:03:35 PM GMT+02:00, Andrew Stubbs <[hidden email]> wrote:

>Hi all,
>
>I'm in the process of trying to update our AMD GCN port from GCC 7 to
>GCC 8+, but I've hit a problem ...
>
>It seems there's a new assumption that pointers and addresses will be
>scalar, but GCN load instructions require vectors of pointers.
>Basically, machine_mode has been replaced with scalar_int_machine mode
>in many places, and we were relying on vector modes being allowed.
>
>The changes are all coming from the Richard Sandiford's SVE patches.
>
>Is there a new way of dealing with vectors of pointers?

Maybe you can masquerade it behind a large scalar integer mode?...

Richard.

>Thanks
>
>Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Vector pointer modes

Andrew Stubbs-4
On 16/05/18 17:24, Richard Biener wrote:
> On May 16, 2018 6:03:35 PM GMT+02:00, Andrew Stubbs <[hidden email]> wrote:
>> Is there a new way of dealing with vectors of pointers?
>
> Maybe you can masquerade it behind a large scalar integer mode?...

We're using V64DImode to represent a vector of 64 64-bit pointers. The
architecture can hold this in a pair of V64SImode registers; it is not
equivalent to 128 consecutive smaller registers, like NEON does.

We could use plain DImode to get the same effect from print_operand, but
that then chooses the wrong alternative, or whole wrong insn pattern and
bad things would happen.

Or, do you mean something else?

Andrew
Reply | Threaded
Open this post in threaded view
|

Re: Vector pointer modes

Richard Biener-2
On May 16, 2018 6:35:05 PM GMT+02:00, Andrew Stubbs <[hidden email]> wrote:

>On 16/05/18 17:24, Richard Biener wrote:
>> On May 16, 2018 6:03:35 PM GMT+02:00, Andrew Stubbs
><[hidden email]> wrote:
>>> Is there a new way of dealing with vectors of pointers?
>>
>> Maybe you can masquerade it behind a large scalar integer mode?...
>
>We're using V64DImode to represent a vector of 64 64-bit pointers. The
>architecture can hold this in a pair of V64SImode registers; it is not
>equivalent to 128 consecutive smaller registers, like NEON does.
>
>We could use plain DImode to get the same effect from print_operand,
>but
>that then chooses the wrong alternative, or whole wrong insn pattern
>and
>bad things would happen.
>
>Or, do you mean something else?

I was thinking of using ZImode where hopefully ZI is large enough to hold V64DI...

Richard.

>Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Vector pointer modes

Richard Sandiford-7
In reply to this post by Andrew Stubbs-4
Andrew Stubbs <[hidden email]> writes:

> Hi all,
>
> I'm in the process of trying to update our AMD GCN port from GCC 7 to
> GCC 8+, but I've hit a problem ...
>
> It seems there's a new assumption that pointers and addresses will be
> scalar, but GCN load instructions require vectors of pointers.
> Basically, machine_mode has been replaced with scalar_int_machine mode
> in many places, and we were relying on vector modes being allowed.
>
> The changes are all coming from the Richard Sandiford's SVE patches.

FWIW, I think that assumption was always there.  The scalar_int_mode
patches just made it more explicit (as in, more code would fail to
build if it wasn't honoured, rather than just potentially ICEing).

Is this mostly about the RTL level concept of an address or pointer?
If so, in what situations do you need the address or pointer itself to
be a vector?  SVE and AVX use unspecs for gathers and scatters, and I
don't think in practice we lose anything by doing that.

Thanks,
Richard
Reply | Threaded
Open this post in threaded view
|

Re: Vector pointer modes

Andrew Stubbs
On 16/05/18 22:01, Richard Sandiford wrote:

> Andrew Stubbs <[hidden email]> writes:
>> Hi all,
>>
>> I'm in the process of trying to update our AMD GCN port from GCC 7 to
>> GCC 8+, but I've hit a problem ...
>>
>> It seems there's a new assumption that pointers and addresses will be
>> scalar, but GCN load instructions require vectors of pointers.
>> Basically, machine_mode has been replaced with scalar_int_machine mode
>> in many places, and we were relying on vector modes being allowed.
>>
>> The changes are all coming from the Richard Sandiford's SVE patches.
>
> FWIW, I think that assumption was always there.  The scalar_int_mode
> patches just made it more explicit (as in, more code would fail to
> build if it wasn't honoured, rather than just potentially ICEing).

It was fine if done late enough, but now it's just blocked in
TARGET_ADDR_SPACE_POINTER_MODE et al.

However, having now finished a first rough forward-port (with the
relevant bits of these hooks commented out and gcc_unreachable), I find
that vector loads and stores are working perfectly, and there are no
related ICEs in the testsuite (although, with vector widths less than 64
still on the to-do list, a lot of the testsuite doesn't do much
vectorizing).

> Is this mostly about the RTL level concept of an address or pointer?
> If so, in what situations do you need the address or pointer itself to
> be a vector?  SVE and AVX use unspecs for gathers and scatters, and I
> don't think in practice we lose anything by doing that.

As far as the ISA is concerned, *all* vector loads and stores are
scatter/gather.

In our port we model a normal, contiguous vector load/store as a DImode
base pointer until reload_completed, and then have a splitter expand
that into a V64DImode with the appropriate set of lane addresses.
Ideally this would happen earlier, so as to allow CSE to optimize the
expansion, but we've not got there yet (and, as you say, would probably
hit trouble).

Andrew