CodeGenPrepare pass move extension instructions close to load instructions in different BB, so they can be combined later. But the extension instructions can't move through logical and shift instructions in current implementation. This patch enables this enhancement, so we can eliminate more extension instructions.
Details
- Reviewers
qcolombet - Commits
- rGc4c6b548c5bd: [CodeGenPrepare] Move Extension Instructions Through Logical And Shift…
rG1aea95a9eafa: [CodeGenPrepare] Move Extension Instructions Through Logical And Shift…
rL334049: [CodeGenPrepare] Move Extension Instructions Through Logical And Shift…
rL331783: [CodeGenPrepare] Move Extension Instructions Through Logical And Shift…
Diff Detail
- Repository
- rL LLVM
Event Timeline
Not really my area of expertise - just skimming the commit history for the file it looks like Quentin did a bunch of nearby work, so perhaps he can help?
Hi,
High level comment to help me dive into your changes.
See inlined.
Cheers,
Q
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
3254 ↗ | (On Diff #142076) | Could you add comments explaining what the new parameters are and their use? |
test/Transforms/CodeGenPrepare/X86/ext-logicop.ll | ||
1 ↗ | (On Diff #142076) | Could you run opt instnamer on the input file first? |
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
3254 ↗ | (On Diff #142076) | The new parameters are used to check:
|
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
3246 ↗ | (On Diff #143654) | typo: instruction |
3257 ↗ | (On Diff #143654) | Both IsSExt and ConsideredExtType can be derived from ExtInst now. |
3370 ↗ | (On Diff #143654) | I believe this check does not belong here. |
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
3246 ↗ | (On Diff #143654) | deleted. |
3257 ↗ | (On Diff #143654) | Parameter ExtInst is deleted. |
3370 ↗ | (On Diff #143654) | Removed. It directly makes parameter TLI unnecessary. Another use of ExtInst in pattern and(ext(shl(opnd, cst)), cst) can be found through its user since it must be the only user. So we can keep the interface unchanged. |
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
3369 ↗ | (On Diff #143806) | Do we need to restrict this to constants? |
3382 ↗ | (On Diff #143806) | Same question as And and Or, do we need to restrict to constant? |
3386 ↗ | (On Diff #143806) | Same comment as the previous one. |
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
3369 ↗ | (On Diff #143806) | It is same as DAGCombiner::visitZERO_EXTEND. Extension of constant doesn't cause extra cost at run time, it makes sure moving extension across this instruction doesn't bring another extension on the other operand. Only in rare case the extension on the other operand can also be combined with another load. |
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
3369 ↗ | (On Diff #143806) | Agreed. However, the check of the profitability of creating more than one extension is done later. Here we focus on answering, is it possible to extend? My point is, unless you see a problem with the existing cost model used later, we shouldn't prevent the promotion to get evaluated. |
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
3369 ↗ | (On Diff #143806) | Sounds reasonable. The source code is: ; Don't do the folding if the other operand isn't a constant. %bf.load = load i8, i8* %data, align 4 %bf.clear = lshr i8 %bf.load, 2 %0 = or i8 %bf.clear, %logop %1 = zext i8 %0 to i64 ret i64 %1 } Original result is: movb (%rdi), %al shrb $2, %al orb %sil, %al movzbl %al, %eax retq Now the result is: movzbl (%rdi), %ecx shrq $2, %rcx movzbl %sil, %eax orq %rcx, %rax retq The new result isn't better than old result, neither worse. Do you think we should do transformation on this test case? |
The new result isn't better than old result, neither worse. Do you think we should do transformation on this test case?
Yes. As long as it isn't worse, that means the cost model works the way we want.