[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |SUSPENDED
   Last reconfirmed|                            |2021-02-20

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
I added an issue to the experimental branch :

https://github.com/iains/gcc-darwin-arm64/issues/43

And produced two patches to work around the issue (although the first should
tighten up the constraint on prf*m for all targets).

--

The first patch is a conservative fix, it just prevents the generation of pfrm
insns when the offset is out of range (and when it would require pfrum for
Darwin)

https://github.com/iains/gcc-darwin-arm64/commit/2fbd9a7f9cddc7e243c0025713841e0bc1465c41

The second patch adds predicate, constraint and patterns for the prfum insn,
which means that Darwin now generates:

prfum [X0, -8]

which is accepted by the LLVM backend,

https://github.com/iains/gcc-darwin-arm64/commit/881a59f2258a5a7a9c2c862420c4e93e9df17f2c

====

Given some more time, I expect that the two could be combined in some way; at
least unless/until LLVM gets a fix and that percolates through to Xcode.

So the bug is "fixed on the experimental branch".

Given that it cannot be fixed on GCC 'upstream' until we have a chance to
submit the port (which isn't ready yet!) .. I suggest that "SUSPEND" is a
reasonable state for this bug.