Re: Vector pointer modes

[Andrew Stubbs <andrew_stubbs at mentor dot com>]

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