[PATCH] D31821: Remove redundant copy in recurrences
Wei Mi via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri May 19 12:04:45 PDT 2017
wmi added a comment.
Hi Taewook,
Thank you for working on it. The testcase you gave is interesting. My previous work in isRevCopyChain is quite limited and only handle recurrence within a BB, so I like to see a more general fix about the redundent copy problem caused by recurrence.
A problem of the patch I can see is that it uses dataflow to track the recurrence, which I think may not be enough. Think about the case below:
r3 = r4;
...
r1 = r2 + r3;
...
r5 = load(r1)
r4 = r5;
r1-->r5-->r4-->r3-->r1, it is a recurrence loop according to the algorithm, however, we don't have problem to coalesce r3 with r4 and coalesce r4 and r5, because r5 and r1 don't have to be allocated to the same register.
So the def-src constructing an recurrence chain interesting for us should only contains def and src which are in a tied operand group, or which are in the same copy. In other word, the recurrence chain can only cause redundent copy problem when all the operands on the chain have to be allocated to the same register. That kind of recurrence loop is what we are interested in.
In addition, I don't think the recurrence chain has to be a strict cycle. Just like your motivational testcase:
vreg0 = vreg13
...
vreg2 = vreg15
vreg10 = add vreg1, vreg0
vreg3 = add vreg2, vreg10
vreg13 = vreg3
Here the recurrence chain starting from vreg0 is: vreg0-->vreg13-->vreg3-->vreg2. This is not a strict cycle, however, vreg2 and vreg0 already have interference with each other. It means it is impossible to allocate all the vregs in the recurrence chain to the same physical register, and some copy has to be kept.
I think those are the two issues that have to be addressed for a more general solution to the recurrence problem.
Thanks,
Wei.
https://reviews.llvm.org/D31821
More information about the llvm-commits
mailing list