[llvm] [SPIRV] Handle unknown intrinsics (PR #166284)

[Alex Voicu via llvm-commits]

https://github.com/AlexVlx commented:

> TBH I'm not the greatest fan of this llvm-spirv option. Usually when compilation comes to this point the intrinsics should be resolved by the SPIR-V generator. Also even if the intention is to have them translated back to LLVM IR it opens some uncomfortable questions regarding change of the semantics or intrinsics' postfixes for overloads (for example switch from typed to untyped pointers made some intrinsics incompatible (at least out of a box)).
> 
> On the other hand there are vendor specific intrinsics, that might not have a counterpart in the upstream LLVM or that are better not to be emulated.
> 
> How do you feel about always requiring a Prefix for --spv-allow-unknown-intrinsics? Like this we could at least create a notion, that 'native' LLVM intrinsics should be lowered to SPIR-V appropriately? 

I agree overall, it's not ideal, but as you correctly point out, it's extremely unlikely that we'll ever be in a position to handle useful target specific intrinsics in a more meaningful way. Always requiring a prefix seems reasonable, however it would probably be aspirational at this point (as the test itself outlines, we have gaps around fairly boring things like `readcyclecounter`). That would still be fine though as the user could explicitly specify `llvm.` as the prefix and still make progress, being able to do away with the option / constrain it to only match target specific intrinsics. I assume this is what you had in mind, and not outright banning ever handling `native` LLVM intrinsics via this mechanism.

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