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

[Daniel Berlin]

On Wed, Jun 18, 2014 at 12:56 PM, Tobias Grosser <tobias at grosser.es> wrote:
> 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?

+1
Little passes like this, created because other infrastructure
currently sucks and needs serious work, seem somewhat inevitable as
temporary things, but they do eat at compile time, so it's always good
to do what you can to limit impact, even if it means not catching
everything.


>
> Tobias