[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