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

[Gerolf Hoflehner]

Theoretically the algorithm is quadratic in the number of loads and stores. 

The first thought was to integrate it with GVN using a hash table approach Daniel is referring to. It seemed the natural place to look at for deciding when two instructions are equivalent. But the code got unwieldy quickly resulting in an increase in GVN code size which made it look unlikely to get accepted by the community. And you still search the hash table. It could potentially give better compile-time results in cases when there are a few loads and lots of other instructions (the good case of space-time trade-off), but not when eg. the blocks have loads only. In the end it seemed cleanest to move the optimization into its own pass and make it conservative, so that compile-time impact should be negligible.

-Gerolf


On Jun 11, 2014, at 9:04 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> It's not possible to do a *complete* job of store sinking/load
> hoisting in better time bounds.
> 
> However,  it is possible to do *this* particular part of it in better
> time bounds (through creative use of value numbering loads and a hash
> table).  LLVM doesn't have the infrastructure right now to make this
> easy, however.
> 
> 
> 
> 
> 
> 
> On Tue, Jun 10, 2014 at 11:15 PM, Tobias Grosser <tobias at grosser.es> wrote:
>> On 10/06/2014 22:43, Gerolf Hoflehner wrote:
>>> 
>>> Hi chandlerc,
>>> 
>>> This pass iteratively hoists two loads to the same address out of a
>>> diamond (hammock) and merges them
>>> into a single load in the header. Similar it sinks and merges two stores
>>> to the tail block. The algorithm
>>> iterates over the instructions of one side of the diamond and attempts to
>>> find a matching load/store on
>>> the other side. It hoists / sinks when it thinks it safe to do so.  I
>>> tailored the code as conservative as possible to catch the initial cases we
>>> are interested in, which keeps code size and complexity in check. The
>>> optimization helps hiding load latencies and triggering if-conversion.
>>> 
>>> http://reviews.llvm.org/D4096
>> 
>> 
>> Hi Gerolf,
>> 
>> just a high-level comment. This algorithm seems to have quadratic run time.
>> Is this intended?
>> 
>> Cheers,
>> Tobias
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits