================
@@ -62,6 +63,18 @@ LLVM_ABI StringRef getName(ID id);
 /// overloading, such as "llvm.ssa.copy".
 LLVM_ABI StringRef getBaseName(ID id);
 
+/// \returns the target feature expression required by an intrinsic.
+LLVM_ABI StringRef getRequiredTargetFeatures(ID id);
+
+/// Sentinel value for an intrinsic's required-target-features string. When an
+/// intrinsic's \c TargetFeatures is set to this keyword, whether the intrinsic
+/// is supported is decided by a target-specific hook
+/// (TargetSubtargetInfo::isIntrinsicSupportedByTarget) rather than by
+/// evaluating a subtarget feature expression. Use it when support depends on
+/// more than the subtarget features, such as a particular overload/mangling or
+/// argument combination accepted by some targets but not others.
----------------
shiltian wrote:

> whether that call is correct or not seems like a job for the verifier.

Because the verifier cannot be subtarget-dependent. I can think of two cases:

1. An intrinsic's arguments are subtarget-dependent. For example, an intrinsic 
might accept only 0 and 1 on one subtarget, but accept 0, 1, and 2 on another. 
The verifier can only check that the value is one of 0/1/2. If the value is 2 
on a target that doesn't support it, the verifier can't reject it, but 
instruction selection will fail. I think we already have intrinsics like this 
for memory operations, where some control argument has valid values that depend 
on the subtarget.
2. Certain intrinsic manglings are subtarget-dependent. This is also something 
the verifier can't validate.

More generally, anything that is subtarget-dependent falls into this category. 
It can't be fully verified by the verifier, and it also can't always be 
selected correctly by the backend.

> first saying that this change is about intrinsics that depend on target 
> features, and then redefining it to "more than subtarget features" feels like 
> a conflation of two different concerns.

This was about the question from @arsenm about how this infrastructure can 
support the mangling vs sub-target case. We can definitely do it in a follow-up 
if that can help make it easier to move forward.

https://github.com/llvm/llvm-project/pull/201470
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to