This is an archive of the discontinued LLVM Phabricator instance.

[llvm][TableGen] Define FieldInit::isConcrete overload
ClosedPublic

Authored by rriddle on Feb 10 2020, 2:29 PM.

Details

Summary

There are a few field init values that are concrete but not complete/foldable (e.g. ?). This allows for using those values as initializers without erroring out.

Example:

class A {
  string value = ?;
}
class B<A impl> : A {
  let value = impl.value; // This currently emits an error.
  let value = ?;          // This doesn't emit an error.
}

Diff Detail

Event Timeline

rriddle created this revision.Feb 10 2020, 2:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 10 2020, 2:29 PM
rriddle edited the summary of this revision. (Show Details)Feb 10 2020, 2:30 PM
jpienaar accepted this revision.Feb 10 2020, 2:48 PM
jpienaar edited the summary of this revision. (Show Details)
jpienaar added a subscriber: jpienaar.

Looks good thanks

This revision is now accepted and ready to land.Feb 10 2020, 2:49 PM
tra added a comment.Feb 10 2020, 3:04 PM

LGTM, but wait a bit before landing in case @nhaehnle has concerns.

tra accepted this revision.Feb 10 2020, 3:58 PM

LGTM to unblock our build/integration.

This revision was automatically updated to reflect the committed changes.

Do you have a concrete example where this is used? I would have expected the A1.value to be resolved... the non-resolve-behavior was only kept around for bits in instruction encodings (Resolver::keepUnsetBits).

Do you have a concrete example where this is used? I would have expected the A1.value to be resolved... the non-resolve-behavior was only kept around for bits in instruction encodings (Resolver::keepUnsetBits).

This happens in MLIR where we use tablegen quite a bit, e.g. for defining operations.

https://github.com/llvm/llvm-project/blob/272d35aef5e0d32f12b700ea12c608e0323ceb3f/mlir/include/mlir/IR/OpBase.td#L683
https://github.com/llvm/llvm-project/blob/272d35aef5e0d32f12b700ea12c608e0323ceb3f/mlir/include/mlir/IR/OpBase.td#L636

Okay. I prefer the resolution by dsanders in D74796 though, where the field reference ends up fully resolved to a ?