[llvm-dev] loop invariant code hoisting

[Philip Reames via llvm-dev]

On 12/7/20 7:52 AM, Florian Hahn via llvm-dev wrote:
> Hi,
>
>> On Dec 7, 2020, at 13:25, Sjoerd Meijer via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>> Hello,
>>
>> I would like to restrict LICM in the number of memory operations it 
>> hoists out of a loop. Blindly hoisting out all instructions out could 
>> result in a lot of spilling/reloading, which is what I'd like to 
>> avoid. We see this for example on (inner)loops with small constant 
>> bounds that are unrolled. I am drafting something 
>> inhttps://reviews.llvm.org/D92488, which contains a reduced version 
>> of my motivating example.
>> It was brought to my attention that LICM might not have any 
>> restrictions by design because hoisting out all instructions could be 
>> some sort of canonical form that other passes depend on, so sinking 
>> back defs closer to their user(s) might be a back-end problem. I was 
>> wondering if there are any opinions on this.
>>
>
> I think one key benefit of hoisting as much as possible is that it 
> enables/simplifies subsequent optimizations in the middle-end 
> (especially for memory operations). Limiting hoisting is likely to 
> have a bad knock-on effect on other transformations.
>
> Accurately estimating the number of spills in LICM is probably going 
> to be tricky and/or brittle. Another thing to consider is that there 
> are plenty of other transformations that extend live-ranges of values, 
> so they would also need to also need updating.
>
> Sinking in the backend would catch those cases naturally, while making 
> our lives easier in the middle-end. We already have plenty of 
> infrastructure to reason about register pressure & co in CodeGen. As 
> Bardia mentioned, currently there is limited support for 
> re-materialzing instructions.
>
> Besides that, I don’t think there are dedicated passes to move defs to 
> uses to reduce register pressure, beside the MachineScheduler. But the 
> MachineScheduler currently only operates on sub-regions of basic blocks.
>
> I think there would be potential for having a dedicated pass to move 
> defs across basic blocks to reduce register pressure. I think we have 
> most building blocks (RegisterPressureTracker, MachineTraceMetrics for 
> selecting a likely trace through the function). But reasoning about 
> moving memory operations is probably going to be more difficult in the 
> backend than in the middle-end though unfortunately.

I'd explored the notion of doing a register pressure aware global code 
motion a while back.  There's a bunch of hard cases, but there's also a 
bunch of obvious profitable stuff too.  I think this is entirely 
realistic if someone wanted to devote to time.

I doubt this would solve the triggering case for this thread though.  
Despite the framing as being about LICM, the transform actually involved 
was store promotion.  I suspect the issue is that we simply haven't 
considered undoing store promotion in MachineLICM.  (I haven't looked, 
so this may be a false statement.)

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201208/131e386c/attachment-0001.html>