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