Richard Biener wrote:

On Mon, Sep 28, 2026 at 3:20 PM Tobias Burnus <[email protected]> wrote:
I think it is mainly for users of
those GPUs that just pass the argument to the compiler. And instead
of

gcn mkoffload: error: unrecognized argument in option ‘-march=gfx1154’


it is much more helpful to get the following error message:

gcn mkoffload: fatal error: GCC was built without library support for
‘-march=gfx1154’; consider compiling for the associated generic
architecture ‘-march=gfx11-generic’ instead
Can we make that

gcn mkoffload: note: GCC was built without library support for
'-march=gfx1154'; using architecture '-march=gfx11-generic' instead

That was what I had suggested initially, but I think Andrew
preferred back then this solution.

In any case, it works well enough – and the user can then simply
choose the generic one. They could still build the specific one,
if they care only for their hardware (even though it doesn't
make a difference in GCC currently, except with pre-generic
ancient ROCm).

* * *

aka, fall back to gfx11-generic automagically for all gfx11*?

There are some differences which gfx*-generic papers over.
For instance, some gfx9-generic systems support XNACK, others
don't. With a specific system, we can diagnose this, with
generic not.

Likewise, there are minor feature and bug differences between
the gfx*-generic, where the specific version could either use
the extra features or avoid some bugs. However, GCC does not
generate special code for any of the specific ones, compared
to the generic ones.

* * *

Regarding pattern matching all gfx11* as gfx11-generic:

Well, at least AMD thinks that the gfx117{0,1,2} GPUs are
different enough to deserve a gfx11-7-generic. I don't
know whether our code gen currently uses a subset that
covers both gfx11 and gfx11.7 but without more reading
and possibly testing it, I wouldn't bet on it.

In any case, gfx11-generic's ELF flag (0x054) is different
to gfx11-7-generic (0x062) such that ROCm will reject
running a program using the former ELF flag on hardware
of the latter subarch.

Tobias

Reply via email to