[PATCH] D96416: [TableGen] Improve algorithms for processing template arguments; add type checking
Paul C. Anagnostopoulos via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Feb 17 10:36:11 PST 2021
Paul-C-Anagnostopoulos added a comment.
I don't have any good ideas about how to approach this problem. However, while looking around, I'm finding things that confuse me even more. In AMDGPUSearchableTables.td:
class RsrcIntrinsic<AMDGPURsrcIntrinsic intr> {
Intrinsic Intr = !cast<Intrinsic>(intr);
bits<8> RsrcArg = intr.RsrcArg;
bit IsImage = intr.IsImage;
}
. . .
foreach intr = !listconcat(AMDGPUBufferIntrinsics,
AMDGPUImageDimIntrinsics,
AMDGPUImageDimAtomicIntrinsics) in {
def : RsrcIntrinsic<!cast<AMDGPURsrcIntrinsic>(intr)>;
}
Notice that the class casts the 'intr' argument to type Intrinsic. But the lists that are concatenated in the foreach include AMDGPUBufferInstrinsics, which is a list of records of type AMDGPURsrcIntrinsic. That class is not a subclass of Intrinsic. So why aren't a pile of errors produced when trying to cast those record to type Intrinsic?
Ah, but now I see that one of the records in the AMDGPUBufferInstrinsics list is int_amdgcn_buffer_load_format, which is actually of type AMDGPUBufferLoad, which is a subclass of Instrinsic. Another record in the lits is int_amdgcn_s_buffer_load, which is of type Intrinsic. So probably all the record in the list are of type Intrinsic, which means there is no problem casting them.
This points out a problem with defset and/or !listconcat. I think it's !listconcat. But it probably has nothing to do with the issue at hand.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D96416/new/
https://reviews.llvm.org/D96416
More information about the llvm-commits
mailing list