Re: [PATCH 00/25] AMD GCN Port

Re: [PATCH 00/25] AMD GCN Port

[Bernd Edlinger]

<ams@codesourcery.com> writes:
> Given a pattern with a number of operands:
>
> (match_operand 0 "" "=&v")
> (match_operand 1 "" " v0")
> (match_operand 2 "" " v0")
> (match_operand 3 "" " v0")
>
> GCC will currently increment "reject" once, for operand 0, and then decrement
> it once for each of the other operands, ending with reject == -2 and an
> assertion failure.  If there's a conflict then it might try to decrement reject
> yet again.
>
> Incidentally, what these patterns are trying to achieve is an allocation in
> which operand 0 may match one of the other operands, but may not partially
> overlap any of them.  Ideally there'd be a better way to do this.

I have seen something similar in the arm.md:
where this allocation problem is solved differently:

(define_insn_and_split "*arm_subdi3"
  [(set (match_operand:DI           0 "arm_general_register_operand" "=&r,&r,&r")
        (minus:DI (match_operand:DI 1 "arm_general_register_operand" "0,r,0")
                  (match_operand:DI 2 "arm_general_register_operand" "r,0,0")))


DI registers are always consecutive register pairs,
but they should not partially overlap.
They solve that by using alternatives.


Bernd.

[PATCH 00/25] AMD GCN Port

[ams]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

Hi All,

This patch series contains the non-OpenACC/OpenMP portions of a port to
AMD GCN3 and GCN5 GPU processors.  It's sufficient to build
single-threaded programs, with vectorization in the usual way.  C and
Fortran are supported, C++ is not supported, and the other front-ends
have not been tested.  The OpenACC/OpenMP/libgomp portion will follow,
once this is committed, eventually.

If the Steering Committee approve the port and the patches are accepted
then I'd like to see the port make it into GCC 9, please.

The patches, as they are, are not perfect; I still want to massage the
test results a little, but I'd like to find out about big review issues
sooner rather than later.

I've posted the middle-end patches first.  Some of these are target
independent issues, but are included in the series because they are
required for GCN to work properly.

I've then split the back-end patches into libgfortran, libgcc, and the
back-end proper.

Finally I have the testsuite tweaks and fix ups.  I don't have any
GCN-specific tests as yet; the existing tests serve to demonstrate
correctness, and I anticipate future GCN tests being largely
optimization issues, such as instruction selection and vectorization
coverage.

I'm aware that I still need to make the necessary documentation
adjustments.

Thanks in advance

-- 
Andrew Stubbs
Mentor Graphics / CodeSourcery