This is an archive of the discontinued LLVM Phabricator instance.

Allow gep (select) combine with non-constant operands
AbandonedPublic

Authored by rampitec on Apr 29 2020, 4:35 PM.

Details

Summary

This transformation then allows SROA to eliminate allocas
whose address is being selected.

Diff Detail

Event Timeline

rampitec created this revision.Apr 29 2020, 4:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 29 2020, 4:35 PM
arsenm added inline comments.Apr 29 2020, 5:10 PM
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
1729

demorgan this

1731–1732

Calling GetUnderlyingObject so often seems potentially expensive

rampitec marked an inline comment as done.Apr 29 2020, 5:26 PM
rampitec added inline comments.
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.

rampitec marked an inline comment as done.Apr 29 2020, 6:06 PM
rampitec added inline comments.
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
1729

JBTW, demorgan comment or logic?

rampitec updated this revision to Diff 261295.Apr 30 2020, 11:15 AM
rampitec marked an inline comment as done.

Fixed comment and restated condition. Not sure it looks better though.

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:

  1. It will only touch patterns already considered by SROA.
  2. It will give InstCombiner a chance to convert it back if SROA did not succeed.
  3. There is zero chance it will loop forever.
  4. It does not call expensive GetUnerlyingObject.

If those two look better I would prefer modifications in SROA and drop this.

spatel added a comment.May 1 2020, 8:55 AM

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:

  1. It will only touch patterns already considered by SROA.
  2. It will give InstCombiner a chance to convert it back if SROA did not succeed.
  3. There is zero chance it will loop forever.
  4. 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).

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:

  1. It will only touch patterns already considered by SROA.
  2. It will give InstCombiner a chance to convert it back if SROA did not succeed.
  3. There is zero chance it will loop forever.
  4. 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).

Right, I hope these two SROA patches can land instead of this.

Can this be abandoned now?

rampitec abandoned this revision.May 27 2020, 4:29 PM

Can this be abandoned now?

D79217 only partially solves the problem, there is also D79218 needed. I am going to abandon this anyway.