[PATCH] Review for hoisting and sinking of equivalent memory instruction (Instruction Merge Pass)
ghoflehner at apple.com
Thu Jun 12 17:40:03 PDT 2014
I changed the name from IM to InstructionMerger and acknowledge it is not ideal, but neither are the alternative proposals. Does anyone else feel strongly against the name?
On Jun 11, 2014, at 10:34 AM, Philip Reames <listmail at philipreames.com> wrote:
> As I said in the other thread, I do not support the current name. Here are a few ideas:
> - You're hoisting and sinking loads and stores across branches. Maybe: LSHoistSink
> - This is analogous to LICM, but without loops. Maybe: BranchICM?
> I would argue *strongly* that the current name should not be accepted. It is not descriptive and is actively confusing.
> The rest of my comments will be on the phabricator review. I wanted to continue this in email since that's where it had previously started.
> On 06/10/2014 01:43 PM, 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.
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits