Page MenuHomePhabricator

[tablegen] Add !iscomplete(Value)
Needs ReviewPublic

Authored by dsanders on Feb 18 2020, 2:35 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

It's currently very difficult to distinguish 0 from ? in TableGen.
Comparisons such as !eq(?, 0) currently assert on the ? because it isn't
a TypedInit, and !eq({?}, 0) is true because bits<> coerces ? to 0. For
the same reason !isa<int>(?) and !isa<int>({?}) give different outcomes
because ? isn't convertible to int (and is therefore not foldable), even
though {?} is.

As part of this there is a slight relaxation to the folding requirements
of FieldInit so that field references are folded if they have a Concrete
value (fully evaluated) rather than a Complete value (fully evaluated but not
containing ?).

Event Timeline

dsanders created this revision.Feb 18 2020, 2:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 18 2020, 2:35 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
dsanders retitled this revision from Add !iscomplete(Value) to [tablegen] Add !iscomplete(Value).Feb 18 2020, 2:49 PM

I like this direction. Please add !iscomplete to the documentation, plus some more comments inline.

llvm/test/TableGen/field-access-initializers.td
11

Thank you, this makes much more sense.

llvm/test/TableGen/isa-consistency.td
34

That comment is out of place now, isn't it?

51

Same.

60–61

Same.

llvm/test/TableGen/iscomplete.td
160–162

It doesn't assert, does it? Rather it produces an error message.

dsanders updated this revision to Diff 245477.Feb 19 2020, 11:14 AM
dsanders marked 4 inline comments as done.

Additional comments

llvm/test/TableGen/isa-consistency.td
34

Z4's ret still fails to resolve like it did before this change. The check is what I'd expect from it but we actually get:

llvm-project/llvm/test/TableGen/isa-consistency.td:37:1: error: Initializer of 'ret' in 'Z4' could not be fully resolved: !isa<int>(?)

I'm not sure what the cause of the inconsistency is but I believe the type of the field A is being accounted for in a way that ? and !cast<int>(?) somehow don't.

Overall, this file is documenting the strange behaviour of isa<> that I ran into while trying to distinguish ? from 0. I haven't changed that behaviour at all. I've added a comment to the top of the test to explain that

51

It's still the case that the !cast<bit>(?) in Z5 doesn't work but the {?, ?} in Z6 does.
We get the same error as Z4 but with a different expression

60–61

It's still the case that the !cast<int>(?) in Z5 doesn't work but the {?, ?}{0} in Z7 does. This one appears to be due to it having the type bits<1> instead of bit which is a bit surprising but does make some sense.

llvm/test/TableGen/iscomplete.td
160–162

This bit is talking about the original bug where it was asserting. I've added a bit mentioning that it now errors out properly