[llvm] [DirectX][NFC] Leverage LLVM and DirectX intrinsic description in DXIL Op records (PR #83193)
S. Bharadwaj Yadavalli via llvm-commits
llvm-commits at lists.llvm.org
Wed Feb 28 11:33:23 PST 2024
================
@@ -102,50 +91,67 @@ static ParameterKind lookupParameterKind(StringRef typeNameStr) {
return paramKind;
}
+/// Construct an object using the DXIL Operation records specified
+/// in DXIL.td. This serves as the single source of reference for
+/// C++ code generated by this TableGen backend.
DXILOperationDesc::DXILOperationDesc(const Record *R) {
- OpName = R->getValueAsString("OpName");
+ OpName = R->getNameInitAsString();
OpCode = R->getValueAsInt("OpCode");
- OpClass = R->getValueAsDef("OpClass")->getValueAsString("Name");
- Category = R->getValueAsDef("OpCategory")->getValueAsString("Name");
- if (R->getValue("llvm_intrinsic")) {
- auto *IntrinsicDef = R->getValueAsDef("llvm_intrinsic");
+ Doc = R->getValueAsString("Doc");
+
+ if (R->getValue("LLVMIntrinsic")) {
+ auto *IntrinsicDef = R->getValueAsDef("LLVMIntrinsic");
auto DefName = IntrinsicDef->getName();
assert(DefName.starts_with("int_") && "invalid intrinsic name");
// Remove the int_ from intrinsic name.
Intrinsic = DefName.substr(4);
+ // NOTE: It is expected that return type and parameter types of
+ // DXIL Operation are the same as that of the intrinsic. Deviations
+ // are expected to be encoded in TableGen record specification and
+ // handled accordingly here. Support to be added later, as needed.
+ // Get parameter type list of the intrinsic. Types attribute contains
+ // the list of as [returnType, param1Type,, param2Type, ...]
+ auto TypeList = IntrinsicDef->getValueAsListInit("Types");
+ unsigned TypeListSize = TypeList->size();
+ OverloadParamIndex = -1;
+ // Populate return type and parameter type names
+ for (unsigned i = 0; i < TypeListSize; i++) {
+ OpTypeNames.emplace_back(TypeList->getElement(i)->getAsString());
+ // Get the overload parameter index.
+ // REVISIT : Seems hacky. Is it possible that more than one parameter can
+ // be of overload kind?? REVISIT-2: Check for any additional constraints
+ // specified for DXIL operation restricting return type.
+ if (i > 0) {
+ auto &CurParam = OpTypeNames.back();
+ if (lookupParameterKind(CurParam) >= ParameterKind::OVERLOAD) {
+ OverloadParamIndex = i;
+ }
+ }
+ }
+ // Determine the operation class (unary/binary) based on the number of
+ // parameters As parameter types are being considered, skip return type
+ auto ParamSize = TypeListSize - 1;
+ if (ParamSize == 0) {
+ OpClass = "Nullary";
+ } else if (ParamSize == 1) {
+ OpClass = "Unary";
+ } else if (ParamSize == 2) {
+ OpClass = "Binary";
+ } else {
+ // TODO: Extend as needed
+ llvm_unreachable("Unhandled parameter size");
+ }
+ // NOTE: For now, assume that attributes of DXIL Operation are the same as
+ // that of the intrinsic. Deviations are expected to be encoded in TableGen
+ // record specification and handled accordingly here. Support to be added
+ // later.
----------------
bharadwajy wrote:
Done.
https://github.com/llvm/llvm-project/pull/83193
More information about the llvm-commits
mailing list