This transformation then allows SROA to eliminate allocas
whose address is being selected.
Details
- Reviewers
arsenm john.brawn spatel
Diff Detail
Event Timeline
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
1731–1732 | I can just disable this combine unconditionally. In many cases gep is a no-op. However, I in some situations gep really results in some arithmetic. I.e. it is a tradeoff between code quality and compile time. Also note, GetUnderlyingObject has a threshold, which will limit compile time impact on one hand, but also limit optimization on another. |
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
1729 | JBTW, demorgan comment or logic? |
In fact I have created two more changes: D79217 and D79218 to process select and phi with gep operands right in SROA. It is more code but looks cleaner:
- It will only touch patterns already considered by SROA.
- It will give InstCombiner a chance to convert it back if SROA did not succeed.
- There is zero chance it will loop forever.
- It does not call expensive GetUnerlyingObject.
If those two look better I would prefer modifications in SROA and drop this.
If we can deal with this in SROA directly, that would be better. We generally do not want to increase instruction count in InstCombine (as the 2nd test is showing here).
demorgan this