[llvm] [SPIRV] Support for SPV_INTEL_fpga_reg extension (PR #134352)

[Aaron Ballman via llvm-commits]

================
@@ -238,6 +238,22 @@ static SmallVector<Metadata *> parseAnnotation(Value *I,
                                                 : SmallVector<Metadata *>{};
 }
 
+static bool lowerAnnotation(IntrinsicInst *II) {
+  std::string Anno =
+      getAnnotation(II->getArgOperand(1),
+                    4 < II->arg_size() ? II->getArgOperand(4) : nullptr);
+  if (Anno == "__builtin_intel_fpga_reg") {
----------------
AaronBallman wrote:

> @AaronBallman could you please advise us here?
> 
> My understanding that it should be either upstreaming handling of the builtin from https://github.com/intel/llvm/blob/sycl/clang/lib/CodeGen/CGBuiltin.cpp#L6377 to llvm.org (so this `__builtin_intel_fpga_reg` string wouldn't be 'magical' for llvm.org) or adding a brand-new intrinsic for this.
> 
> **Pros** for the upstream:
> 
>     * everything would work out of the box for SPIR-V backend and LLVM IR to SPIR-V translator;
> 
> 
> **Cons**:
> 
>     * I'm not sure how clang folks would react on this, that is why I called Aaron for help;

I think introducing a new builtin to upstream Clang would be reasonable for this, but

>     * As you see, intel/llvm implementation uses `annotation` intrinsics for this, and LangRef says about them:
>       "These have no other defined use; **transformations preserve annotations on a best-effort basis but are allowed to replace the intrinsic with its first argument** without breaking semantics and the intrinsic is completely dropped during instruction selection."
>       For SYCL compiler in intel/llvm it is (was) fine, as for FPGA the code is (was) always compiled with disabled frontend optimizations and the appropriate annotation intrinsics always survive until SPIR-V is generated. I don't know what design do you have an how you will use the extension E2E to claim, that annotations will also work fine for your flow.

I agree that this will be a issue, I don't think an annotation is the right way to go (probably requires an LLVM intrinsic for Clang to lower the builtin to).


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