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


Reply via email to