[PATCH] D127739: [TableGen] Check if input string of !isa is an instance of record type

Artem Belevich via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 15 10:47:11 PDT 2022


tra added a comment.

In D127739#3584132 <https://reviews.llvm.org/D127739#3584132>, @pcwang-thead wrote:

> I have considered adding a new operator `!instanceof<T>(s)` to check if whether a record with type `T` and name `s` exists, but I think `!isa` have the same semantic meaning with `!instanceof`,

The difference is that for C++ (and AFAICT in Java, based on your description), std::string or StringRef is just another class, while here a string is distinct from a record and we may need to distinguish the two.

>> E.g. I may want `!isa<R>(x)` to be false for any 'x' that's not an instance of `R`, even if `x` is a string with a value that matches the name of an existing record of `R`?
>
> I don't know if this feature is needed, I haven't found any usage like this in upstream. The most common scenario where we need a `!isa` is, we pass a record of superclass and then check if it is an instance of some subclasses.

I agree that being able to determine existance of a named record is useful. 
What I have concerns about is whether `!isa` is the right mechanism for that.
We're considering adding new functionality to the tablegen language and need to consider how it can be used or abused once it's in place. As I've pointed above, distinguishing between a string and a record is something that `!isa` would need to handle.

>> Or, perhaps, we should consider extending `!cast` to accept an additional value to be returned if the cast has failed.
>
> Agree, this can be feasible. I will have a try, but I still think we need something like `!instanceof`. :-)

I'm fine with `!instanceof`, too. It would be cleaner than 'overloading' `!cast` with an extra argument.

@nhaehnle - WDYT?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127739/new/

https://reviews.llvm.org/D127739



More information about the llvm-commits mailing list