On 07/02/2025 10:17, Tobias Burnus wrote:
This patch is part of the following series (not yet in mainline);
this patch depends on the first one, but only makes sense if both are in:
* "[gcn] Add gfx9-generic and generic-associated gfx*"
(email subject: "Re: [Patch] [GCN] Handle generic ISA names in
libgomp's plugin-gcn.c";
this thread), https://gcc.gnu.org/pipermail/gcc-patches/2025-
February/675259.html
* "[Patch] [GCN] Handle generic ISA names in libgomp's plugin-gcn.c",
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675274.html
* * *
This patch handles the following case (in mkoffload.cc):
* If for the specified specific device, no (multi)lib is available but for
its generic ISA, automatically choose the generic ISA (with a warning).
Due to the double condition (not available for specified, available for
generic), it shouldn't cause surprises. Additionally, when not using
mkoffload, i.e. when compiling directly with the GCN compiler, the
specific ISA is still used.
As currently no one will build a multilib for gfx*generic and ship it,
the change should not cause surprises to users. And once ROCm supports
it, rebuilding GCC with the added multilib is enough.
Thus, like the libgomp change, it make GCC future proof and aid
deployment by Linux distros.
OK for mainline?
Tobias
I think the correct place for this whole concept might be in the
MULTILIB_MATCHES configuration option, not in mkoffload. We can perhaps
do something with an awk script
In general, I think there's an argument for only having generic arch
libraries, where possible, once the prerequisites are a non-issue.
What's the motivation for adding the warning? I don't think any of the
restrictions are so interesting for library code. In theory there are
some restricted instructions that might be used in libm, perhaps, at
some future time, but that's all. The register count restrictions are
not interesting at all, since that restricts occupancy, not usage (which
is already limited by the ABI).
This business of changing the -march flag from what the user specified
is also questionable.
Andrew
