This is an archive of the discontinued LLVM Phabricator instance.

[LICM] Untangle some of the logic in LICM canSinkOrHoistInst
Needs ReviewPublic

Authored by trentxintong on Jan 3 2017, 9:55 AM.

Details

Summary

This patch fixes 2 problems.

  • For some instructions that work on SSA values, we check isSafeToExecuteUnconditionally twice in case of hoisting. This is unnecessary.
  • For the same set of instructions that work on SSA values, we fail to sink them if they can not meet conditions in isSafeToExecuteUnconditionally. This is a missed opportunity, we can sink these instructions (with no side effects) to the dominated exit blocks, even they do not meet the conditions in isSafeToExecuteUnconditionally. I added a test to demostrate this.

Event Timeline

trentxintong retitled this revision from to [LICM] Untangle some of the logic in LICM canSinkOrHoistInst.
trentxintong updated this object.
trentxintong added a subscriber: llvm-commits.
danielcdh added inline comments.Jan 3 2017, 10:58 AM
lib/Transforms/Scalar/LICM.cpp
366

isSafeToExecuteUnconditionally will not be called in this function, is it safe?

422

isSafeToExecuteUnconditionally was called twice (without the patch):

  • once in canSinkOrHoistInst, with CtxI=nullptr
  • once here, with Ctxl=CurLoop->getLoopPreheader()->getTerminator()

I'm not quite familiar with isSafeToExecuteUnconditionally, but looks to me different CtxI may have different meaning to check? Or am I missing something?

mkuper edited edge metadata.Jan 3 2017, 11:47 AM

I'm a bit confused about the distinction between "legal" and "safe". I'd assume them to mean the same thing.

lib/Transforms/Scalar/LICM.cpp
422

Passing CtxI == nullptr is conservative w.r.t any other CtxI, so that looks like it should be fine.

trentxintong added inline comments.Jan 3 2017, 2:20 PM
lib/Transforms/Scalar/LICM.cpp
366

I think it is safe.

This is the way I see LICM in case of sinking.

Say originally, the sunk instruction is InstructionX in BasicBlockX

Is there a way we sink the instruction to some exit blocks where the instruction is used and the exit block could get executed even the BBX does not. (If thats the case we may have a problem as its not safe to speculate the instruction then). From what I see, we cant, because if we use InstructionX in this exit block in a special _single incoming value_ phi node, BBX must dominate this exit block. This means by the time we execute the exit block, BBX must have been executed already.

NOTE: There is the case of the block not dominating the exit block where the value is used, this is done by Phi nodes with multiple incoming value in the exit block. Then we would not sink this value. This is checked in isNotUsedInLoop.

I'm a bit confused about the distinction between "legal" and "safe". I'd assume them to mean the same thing.

By "legal" I mean the instructions in question is loop invariant, i.e. every iteration of the loop, same value is produced.

By "safe" I mean its safe to speculate the instruction, i.e. the compiler will not create a program that faults given a program that does not fault. In case of hoisting, we can guarantee so by either of the isSafeToSpeculativelyExecute or isGuaranteedToExecute.

I feel word choices can be improved. "Legal" ==> "Loop Invariant" and "Safe" ==> "Safe To Execute Unconditionally"

junbuml added a subscriber: junbuml.Jan 4 2017, 6:53 AM
trentxintong edited edge metadata.

Rework the sinking and hoisting logic a bit more. And also take into existing
suggestions.

trentxintong updated this object.Jan 5 2017, 1:20 PM
trentxintong updated this object.
trentxintong updated this object.
trentxintong updated this object.

I realized what i want to achieve can be done much simpler.

@hfinkel can you please confirm this is correct. Basically, I do not think we need to check for isSafeToExecuteUnconditionally for the set of SSA instructions we handle when we are sinking.

hfinkel edited edge metadata.Jan 8 2017, 5:19 AM

@hfinkel can you please confirm this is correct. Basically, I do not think we need to check for isSafeToExecuteUnconditionally for the set of SSA instructions we handle when we are sinking.

Sinking into the exit block should be safe, subject to aliasing considerations for memory accesses, even for instructions not safe to speculate, so long as it is a dedicated exit (i.e. LI->hasDedicatedExits() returns true).