gc.relocate intrinsic is special in that its second and third operands
are not real values, but indices into relocate's parent statepoint list
of GC pointers.
To be CSE'd, they need special handling in isEqual() and getHashCode().
Details
- Reviewers
reames skatkov - Commits
- rG3c626c714c9d: [EarlyCSE] Common gc.relocate calls.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Just to be clear, if the indices are the same, gc.relocates would already be removed right? i.e. the thing you're trying to solve is that the standpoint can have two operands which are the same value and thus two gc.relocates which are equivalent but not textually identical? Just want to make sure I understand the problem properly.
Another solution to the same problem would be to canonicalize the statepoint in an instcombine rule to avoid duplicate operands in the gc operand section. Have you explored that possibility?
That's right.
Another solution to the same problem would be to canonicalize the statepoint in an instcombine rule to avoid duplicate operands in the gc operand section. Have you explored that possibility?
Well, CSE solution looked to me more elegant - all I need is adjust hash and the rest will be done automatically.
While in instcombine after statepoint operand uniqueing I would have to visit all relocates and update them. Second logical step would be to implement gc.relocate CSE'ing there which I didn't want to do.
And operand uniqueing itself is sort of CSE, so I would need to implement it in InstCombine using some sort of Set etc.
Also, operands might be equivalent, but not textually identical, which InstCombine cannot handle.
(I'm not sure if LLVM's CSE can. This sounds as value numbering).
clang-format suggested style edits found: