Vector pointer modes

Vector pointer modes

[Andrew Stubbs]

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

Re: Vector pointer modes

[Richard Biener]

On May 16, 2018 6:03:35 PM GMT+02:00, Andrew Stubbs <ams@codesourcery.com> 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

Re: Vector pointer modes

[Andrew Stubbs]

On 16/05/18 17:24, Richard Biener wrote:
> On May 16, 2018 6:03:35 PM GMT+02:00, Andrew Stubbs <ams@codesourcery.com> 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

Re: Vector pointer modes

[Richard Biener]

On May 16, 2018 6:35:05 PM GMT+02:00, Andrew Stubbs <ams@codesourcery.com> wrote:
>On 16/05/18 17:24, Richard Biener wrote:
>> On May 16, 2018 6:03:35 PM GMT+02:00, Andrew Stubbs
><ams@codesourcery.com> 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

Re: Vector pointer modes

[Richard Sandiford]

Andrew Stubbs <ams@codesourcery.com> 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

Re: Vector pointer modes

[Andrew Stubbs]

On 16/05/18 22:01, Richard Sandiford wrote:
> Andrew Stubbs <ams@codesourcery.com> 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