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

[Gerolf Hoflehner]

Thanks Daniel & Tobias. 
I think at this point limiting the number of checks and loads makes sense to play it safe for compile-time. 


-Gerolf



 
On Jun 18, 2014, at 1:47 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140618/9363f970/attachment.html>