bogner wrote: I have some misgivings about abusing the target intrinsic infrastructure like this to create "target" intrinsics for a non-existent target. IMO this is morally equivalent to just putting all of these intrinsics as generic llvm intrinsics (`llvm.thread_id` or `llvm.all`), just with some extra namespacing.
For a long time there has been some appetite for being able to strip the target intrinsics for targets you aren't building (see [this very old post](https://discourse.llvm.org/t/lets-stop-using-target-specific-intrinsics-in-generic-code/41783) or the [commit that split up intrinsic headers per-target](https://github.com/llvm/llvm-project/commit/5d986953c8b917bacfaa1f800fc1e242559f76be)). I worry that using the target infrastructure but keyed on something other than a target is a step in the wrong direction there. The other concern is just about layering. Today, backends need to handle generic LLVM intrinsics and their own intrinsics *only*. This is introducing intrinsics that apply across an arbitrary set of backends (DirectX and SPIRV today, possibly some GPU or otherwise SIMT backends in the future...). What's the contract for who needs to handle them? Can we encode that contract in a way that isn't simply best effort as new intrinsics are added? As is, this approach makes those problems harder rather than easier. https://github.com/llvm/llvm-project/pull/87034 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
