[clang] [llvm] [AMDGPU][clang][CodeGen][opt] Add late-resolved feature identifying predicates (PR #134016)

[Alex Voicu via cfe-commits]

================
@@ -9102,6 +9102,15 @@ bool InitializationSequence::Diagnose(Sema &S,
 
   case FK_ConversionFailed: {
     QualType FromType = OnlyArg->getType();
+    // __amdgpu_feature_predicate_t can be explicitly cast to the logical op
+    // type, although this is almost always an error and we advise against it
----------------
AlexVlx wrote:

>From the bottom up, anything but Friday should be good, including today starting from now to now + 6 hours:) I'm in the UK, so the delta is not so large anyway, pick something that fits your schedule and I'll probably be able to make it work.

For your example at the bottom, the ASM is non-problematic in that it goes through. Now substitute it with a builtin that is only there iff SSE3 is available, or try to bind registers from the extended x86_64 set and compile for an x86 target, and it'll go back to failing at compile time. It's that latter part that is problematic even for the user's experience.

I suspect that part of the issue here is that something like X86 hides a lot of this stuff under normal circumstances because folks don't really normally grab for special functionality, or feel the need for it. But if we have a look at the many SIMD extension sets, as well as the attempts at defining various levels of capability (the v1, v2, v3 things) I think the same challenge exists there, it's just not an immediate concern. What we're trying to solve is that whilst it makes perfect sense for a BE, any BE, to bind very tightly to the target, it is sometimes beneficial for the IR coming out of the FE to be generic and usable by many targets, without loss of capability. Without a mechanism as the one here one is either degraded to lowest common denominator capability, or has to play games trying to define capability levels, which generally end up being too coarse.

Also, please note that, in spite of me mentioning x86, at this point we are not proposing this for general use, but rather as a target specific BI, which hopefully reduces risk / contains any perceived novelty to parts where it's already been found to be useful:) 

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