[clang] [clang][X86] Support __attribute__((model("small"/"large"))) (PR #124834)

[Arthur Eubanks via cfe-commits]

================
@@ -1,64 +1,40 @@
-// RUN: %clang_cc1 -triple aarch64 -verify=expected,aarch64 -fsyntax-only %s
+// RUN: %clang_cc1 -triple aarch64 -verify=expected,unsupported -fsyntax-only %s
 // RUN: %clang_cc1 -triple loongarch64 -verify=expected,loongarch64 -fsyntax-only %s
-// RUN: %clang_cc1 -triple mips64 -verify=expected,mips64 -fsyntax-only %s
-// RUN: %clang_cc1 -triple powerpc64 -verify=expected,powerpc64 -fsyntax-only %s
-// RUN: %clang_cc1 -triple riscv64 -verify=expected,riscv64 -fsyntax-only %s
+// RUN: %clang_cc1 -triple mips64 -verify=expected,unsupported -fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc64 -verify=expected,unsupported -fsyntax-only %s
+// RUN: %clang_cc1 -triple riscv64 -verify=expected,unsupported -fsyntax-only %s
 // RUN: %clang_cc1 -triple x86_64 -verify=expected,x86_64 -fsyntax-only %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-cuda -fcuda-is-device -x cuda -verify=expected,unsupported -fsyntax-only %s
----------------
aeubanks wrote:

I'm tempted to keep things as is since it seems like this is not the only issue that can come up with nvptx compiles. For example, the `thread_local` global in the variable has the same issue where nvptx doesn't support thread local globals, which clang complains about, and I don't really see a difference between `__attribute__((model()))` and `thread_local` in that they can both be used on arbitrary globals.

Do you think it's reasonable to postpone this suggestion until people actually hit it? For example, if people aren't hitting the `thread_local` issue, then perhaps people won't hit a warning with this attribute.

https://github.com/llvm/llvm-project/pull/124834