This patch performs check if all the inputs of the BDV are base values themselves (i.e. not derived from some base)
If it's true for some BDV, we can avoid cloning it, because the clone would be identical to BDV (it may have different incoming values, because those may be cloned too).
Details
- Reviewers
mkazantsev reames skatkov nikic
Diff Detail
Event Timeline
llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp | ||
---|---|---|
725 | What worries me is that we never check the consistency of state of IsDerived and BaseValue. There should be some invariant like "if BaseValue is defined and not equal to OriginalValue then IsDerived should be true", or whatsoever. Do you want to add some sanity checks to make sure these states are not self-contradictory? Ideally I'd completely give up a separate boolean flag for IsDerived and answer the method through other fields, but not sure if it's possible. | |
1055 |
| |
1056 | Would that work here? remove_if(States, [](It) { return !It.second.isDerived() ;} ? | |
1089 | Please name the boolean parameter /* IsDerived*/ true |
I'm also looking into this. The idea is clear but I worry this adds a complexity with decoding the state.
I'm looking into the way to make it more straightforward. Probably it will require some re-factoring.
Add more comments, update present ones.
Also there was a crash in lambda getBaseForInput. It relied on the old enum values. Fixed it.
You're extending the algorithm in two ways at once. First, you're tracking whether a value which has a single base is itself that base pointer. Second, you're tracking whether a meet of two values is definitely a base pointer.
I see why the former is needed for the later, but can you get any benefit from only the former? If you can, separating that into it's own patch with tests would help reduce complexity. I think at a minimum you can use the former on its on to strengthen some asserts.
Another way to handle it would be to separate the "IsKnownBase" bit out of the lattice enum states, and track it separately. If you do that, please rename the lattice elements to reflect that they're tracking the number of contributing bases (e.g. unknown, onebase, manybases). We have some precedent for that in the BaseDefiningValueResult structure, so that somewhat makes sense.
llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp | ||
---|---|---|
710 | Naming wise, let me suggest "IsBase" and "HasSingleBase" for the states you're currently calling "Base", and "Derived". Why?
|
Naming wise, let me suggest "IsBase" and "HasSingleBase" for the states you're currently calling "Base", and "Derived".
Why?