[PATCH] Review for hoisting and sinking of equivalent memory instruction (Instruction Merge Pass)

Tobias Grosser tobias at grosser.es
Wed Jun 18 12:56:53 PDT 2014


On 18/06/2014 21:47, Daniel Berlin wrote:
> FWIW: There is no easy way to do this O(n) for stores in LLVM, due to
> the lack of something like memory-ssa (otherwise, you could sink to
> the nearest common dominator of all immediate uses, as we do for GCC)
> You can do it O(n),or much closer, in LLVM for loads, like this:
>
> Assuming GVN and PRE has been run, all loads that can be determined to
> be identical should look identical (if not, our GVN is seriously
> busted :P) in their operands[1]
>
> pending = hash table of <block, load operand> -> list of load instructions
>
> for each load in the diamond:
>    calculate sink location as nearest common dominator of:
>       for each dependency according to memdep, the block of that dependency
>       for each RHS operand, the defining block of that operand.
>    pending[<block, load operands>].insert(load instruction)
>
> for each entry in pending:
> if (list.size() > 1)
>    Perform merge and hoist to end of common dominator block
>
>
> This also would be even easier if GVN produced a value number or value
> handle for each thing, like GCC's (then it wouldn't matter if they
> looked identical, only if they calculate the same value), but c'est la
> vie.
>
> [1] The only case this wouldn't be true is if the load was defined by
> operands in the diamond, in which case you couldn't hoist it out of
> the diamond anyway without a real load PRE determining whether you
> could move/recalculate the operands.

Thanks Daniel!

Gerolf, even if we don't get this algorithm to a linear run-time, does 
it make sense to bound the number of checks such that we don't get a 
quadratic increase in compile time for those corner cases, but that we 
just don't optimize them?

Tobias



More information about the llvm-commits mailing list