================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to