This is an archive of the discontinued LLVM Phabricator instance.

[IR] Refactor SubclassData
Needs ReviewPublic

Authored by ekatz on Jan 1 2020, 11:49 PM.

Details

Summary

A new implementation of the Subclass Data exposed from llvm::Value, which simplifies the process of adding new data/flags into the llvm::Value::SubclassData.

In detail, the new implementation offers the following new features:

  • static assert - that the declared accumulated bitfields do not exceed the underlying subclass data size (note that int the New implementation it is automatically added on declaration)
  • runtime assert - that a new value set, fits into the the bitfield (without truncation).
  • typed - as opposed to using a representative type (like int) and then cast to the actual required type (like bool or enum). Typed (ordinary) bitfields cannot be implemented correctly in MSVC, as the types of all the bitfields must be of the same type. Using typed bitfields also saves us the need to synchronize the use of unsigned/signed int with the actual type needed.
  • declare (a bitfield) in a single line - as opposed to the need to declare helpers or somekind, like enum (manually).
  • clean bitfields - without exposing a bit manipulation enum.
  • automatic inheritance of unused bits - no need to get offset from super (manually).
  • automatic calculation of unused bits - changing a single bitfield doesn't require any other change, but the actual bitfield itself (as opposed to changing also the sum of the bit count used by the class, in an enum - for exmple).
  • implicit reference to superclass - as opposed to the need to use the base class' info explicitly.
  • no need to know anything about any of the base classes.

The core of the change is present in the 2 new files: BitField.h and SubclassData.h (while the other changed files are just refactored to use the new implementation).

An example of the run-time benefits (to add to the compile-time benefits mentioned above):
By using the new implementation, I have managed to move the SSID field (that some Instructions have) into the Subclass Data of the Instructions, and in turn reduce the size of those instructions by 8 bytes.

Diff Detail

Event Timeline

ekatz created this revision.Jan 1 2020, 11:49 PM
rnk added a comment.Jan 15 2020, 11:44 AM

I feel like this is creating too much unnecessary abstraction. I think we can use simple techniques, like unions, as I did here in this uncommitted patch:
https://reviews.llvm.org/D51664#C1373737NL442
Even better, we can do that incrementally, without many changes to the get/set value subclass data APIs.

ekatz added a comment.Jan 15 2020, 1:27 PM
In D72068#1822503, @rnk wrote:

I feel like this is creating too much unnecessary abstraction. I think we can use simple techniques, like unions, as I did here in this uncommitted patch:
https://reviews.llvm.org/D51664#C1373737NL442
Even better, we can do that incrementally, without many changes to the get/set value subclass data APIs.

I do not think it is unnecessary, as we gain so much from it, right away, and also a lot of potential for future improvements.
I think it's worth the benefits listed in the summary.

This may be a large change, but if you look closely, it is not that big of a deal - it is pretty intuitive.
The change is large only due to the large number of subclass data flags.
I can always separate it to 2 changes (or more if possible).

rnk added a comment.Feb 24 2020, 11:10 AM

I'm still basically not in favor of this. If another contributor thinks it's a great idea, I wouldn't go so far as to block this change, but I don't plan to do any further review.

ekatz added a comment.Mar 4 2020, 11:00 AM
In D72068#1889825, @rnk wrote:

I'm still basically not in favor of this. If another contributor thinks it's a great idea, I wouldn't go so far as to block this change, but I don't plan to do any further review.

Fair enough, I respect your opinion.
However, I still think it is a very welcoming change (for the many reasons listed in the "summary"), and I hope other reviewers will see the benefits as I see them, and approve this change.

In D72068#1889825, @rnk wrote:

I'm still basically not in favor of this. If another contributor thinks it's a great idea, I wouldn't go so far as to block this change, but I don't plan to do any further review.

Fair enough, I respect your opinion.
However, I still think it is a very welcoming change (for the many reasons listed in the "summary"), and I hope other reviewers will see the benefits as I see them, and approve this change.

Given the contention around direction, I would suggest that you seek consensus via an RFC on llvm-dev before pinging the patch any further.

ekatz added a comment.Mar 4 2020, 12:16 PM

Given the contention around direction, I would suggest that you seek consensus via an RFC on llvm-dev before pinging the patch any further.

It is the first thing that I did, but I was asked to post the patch for review. I agree that there should have been more discussion in the mail, but it seems stranger (and with not much response) to ping a mail thread.
Please refer to http://lists.llvm.org/pipermail/llvm-dev/2020-January/138710.html for further details.

Given the contention around direction, I would suggest that you seek consensus via an RFC on llvm-dev before pinging the patch any further.

It is the first thing that I did, but I was asked to post the patch for review. I agree that there should have been more discussion in the mail, but it seems stranger (and with not much response) to ping a mail thread.
Please refer to http://lists.llvm.org/pipermail/llvm-dev/2020-January/138710.html for further details.

I think the RFC is the right thing to ping, if you're going to proceed.