[PATCH] D97837: [InstCombine] Remove gc.relocate duplicates

Serguei Katkov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 3 19:04:53 PST 2021


skatkov added a comment.

In D97837#2601652 <https://reviews.llvm.org/D97837#2601652>, @reames wrote:

> Serguei,
>
> At a high level, what's the motivation for this?  After thinking about it a bit, this is essentially just CSE.  CSE is already done by early-cse and gvn.  (In particular, if you run the changed tests through -instcombine -early-cse you get the same result.)
>
> Are you deliberately working around a pass ordering issue here?  Or is there something I'm missing with the patch?

It is interesting. To be honest I did not try cse but gvn did not help me. Makes sense to try while I guess here we cat get a dependency between passes and will need to iterate them in a loop to get the result. In this case I would prefer to move optimization in one pass to reduce compile time.

The motivation case looks as follows:

1. Consider we have a live gc value which is represented as Phi node.
2. RS4GC pass will create a new phi node unconditionally to represent a base and insert both live values (base/derived) into gc-bundle.
3. Then Both relocation (for base and derived pointer) will be created.
4. In the next statepoint where the same value is alive these both relocations will be included into gc-bundle and relocation for both of them will be created.
5. This will be repeated for each next statepoint.

Now optimizations:

1. Something like InstCombine will be able to eliminate the duplicated phi node (created on step 2). And now gc-bundle contains two identical values but different relocations still exist and next statepoint is unchanged.
2. After that InstCombine is able to eliminate extra value from gc-bundle and as a result we have two relocations with the same indices. This is not simplified by InstCombine.
3. You say that CSE is able to eliminate extra gc.relocation and we'll get two identical values in the next statepoint but CSE does not simplify statepoint instruction, so it will stop on that.
4. Next invocation of InstCombine will be able to eliminate extra value in gc-bundle and open CSE way to simplify next relocation.

and so on.
If we have this optimization is in InstCombine, it will be able to simplify the whole chain at once.

Does it make sense?


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

https://reviews.llvm.org/D97837



More information about the llvm-commits mailing list