On 07/01/2024 19:20, Tobias Burnus wrote:
ROCm meanwhile supports also some consumer cards; besides the semi-new
gfx1030, support for gfx1100 was added more recently (in ROCm 5.7.1 for
"Ubuntu 22.04 only" and without parenthesis since ROCm 6.0.0).
GCC has already very limited support for gfx1030 - whose multlib support
is - on purpose - not yet enabled by default and is WIP.
The attached patch now adds gfx1100 on top of it, assuming that it
mostly behaves the same as gfx1030. This is really WIP as there are
known build (assembly) issues (see below) and not only "just" runtime
issues.
gfx1100 differs at least in the following aspects from the previously
supported cards:
* gfx1100 has an 'architected flat scratch' which is different from
'absolute flat scratch' which all others (but fiji: 'offset flat
scratch') have. Hence, '.amdhsa_reserve_flat_scratch 0'
has to be excluded to avoid assembly errors.
* gfx1100 also does not support 'v_mov_b32_sdwa', failing to assembly
libc/argz/libc_a-argz_stringify.o with:
"sdwa variant of this instruction is not supported"
→ This has not been address in the patch, hence, specifying gfx1100 in
--with-multilib-list= will fail to build when an in-tree newlib is build.
* * *
The attached patch fixes in addition one issue in libgomp (string-length
len constant is too short for gfx1030 (and gfx1100) = 7 characters) and
it includes the fix that __gfx1030__ is not defined, which I have
submitted separately (yesterday).
With the caveat that gfx1100 is even less usable than gfx1030 and it
won't build newlib, is it nonetheless
OK for mainline ?
(As gfx1100 is not enabled by default in multilib, a regular build will
will not fail and I think the *.md issue can be addressed separately.)
This looks fine to me. I know there will be things that need fixing for
both experimental architectures.
Andrew
P.S. Apologies, but I think my commits today conflict a little; you
should be able to drop the hunks that patch deleted code.
