bogner wrote: This feels complicated and not very scalable. I don't think we should be implementing ad-hoc vtables via a map of function pointers.
It might be worth sketching out a design for an API that can handle the various cases we're running into here. We need to be able to handle (1) operation maps directly to a generic intrinsic, (2) operation maps to a target intrinsic on one or both of SPIR-V and DX, (3) operation has a generic expansion for some set of targets. Here's one idea. We currently have the getXIntrinsic methods on HLSL runtime, but maybe we should move the abstraction slightly. What if we had CGHLSLRuntime or something like an HLSL builtin builder class with methods like "emitMadOp", "emitClampOp", etc? Then we could specialize this class with a SPIRV HLSL builder and a DirectX HLSL builder, and leave the door open for other specific builders (like AMDGPU) or something like a generic CPU version that expands more things out later. https://github.com/llvm/llvm-project/pull/89130 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
