[PATCH] D93734: [LoopDeletion] Insert an early exit from dead path in loop

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 23 07:42:18 PST 2020


fhahn added a comment.

Thanks for sharing the patch Jonas!

In D93734#2469173 <https://reviews.llvm.org/D93734#2469173>, @jdoerfert wrote:

> In D93734#2469162 <https://reviews.llvm.org/D93734#2469162>, @jonpa wrote:
>
>> In D93734#2469137 <https://reviews.llvm.org/D93734#2469137>, @jdoerfert wrote:
>>
>>> Isn't this more related to LoopUnswitch?
>>> We want to "unswitch the paths that are side-effect free", or something like that.
>>
>> I thought that if we cannot delete the whole loop we can effectively delete a part of it with an early exit.
>
> We delete parts, agreed, but not a loop. Unsure if this is the right place conceptually.
>
>> LoopUnswitching only works if the condition is loop invariant currently as far as I can see, so I am not sure how simple that would be...

As mentioned already, I think framing this as extension to unswitching could be interesting. In a way, it is some kind of 'partial' unswitching, where only the condition of the no-sideeffect version becomes known after unswitching.

I put together an early version of that idea in D93764 <https://reviews.llvm.org/D93764>. It focuses primarily on conditions as in `omnetpp`'s `MACRelayUnitBase::printAddressTable`, where the condition is a load of a loaded address and one the path from the false successor to header/exits has no side effects.  It still an early version(not ready for review yet) which needs more tests and comments, but from looking at the impact on the test-suite (increase in number of branches unswitched), it seems that this could be viable in general.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93734/new/

https://reviews.llvm.org/D93734



More information about the llvm-commits mailing list