================
@@ -873,6 +879,24 @@ AMDGPUTargetMachine::AMDGPUTargetMachine(const Target &T,
const Triple &TT,
TLOF(createTLOF(getTargetTriple())) {
initAsmInfo();
if (TT.isAMDGCN()) {
+ // Triple is missing a representation for non-empty, but unrecognized
+ // subarches. Only permit no subarch for any subtarget if it was really
+ // empty.
+ bool IsUnknownSubArch =
+ TT.getSubArch() == Triple::NoSubArch && TT.getArchName().size() != 6;
+ if (IsUnknownSubArch)
+ reportFatalUsageError("unknown subarch " + TT.getArchName());
+
+ if (TT.getSubArch() != Triple::NoSubArch) {
+ AMDGPU::GPUKind Kind = AMDGPU::parseArchAMDGCN(CPU);
+ Triple::SubArchType GPUSubArch = AMDGPU::getSubArch(Kind);
+ if (Kind != AMDGPU::GK_NONE && GPUSubArch != TT.getSubArch() &&
+ TT.getSubArch() != AMDGPU::getMajorSubArch(GPUSubArch)) {
----------------
slinder1 wrote:
What is the benefit to being like the other targets, though? In many cases
behaving differently is a surprise, but in this case I see the "warn and plow
ahead" behavior as the surprising one.
An e.g. clang user that wants to start using amdgpu won't be confused that they
cannot request nonsense (or just have a typo in their -mcpu??) and the compiler
refuses to ignore them like it does for e.g. x86
We don't have to fix this here, but I wanted to point out that we could
piggyback these kinds of other obvious improvements on the relatively big
effort required to switch over from the "amdgcn" to "amdgpu<subarch>" world.
https://github.com/llvm/llvm-project/pull/206480
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
