[llvm-dev] SimplifyCFG, llvm.loop and latch blocks

[Johannes Doerfert via llvm-dev]

On 4/7/21 12:17 PM, Jeroen Dobbelaere via llvm-dev wrote:
> Hi all,
>
> https://llvm.org/docs/LangRef.html#llvm-loop  states that a llvm.loop is put on the
> 'branch instruction of the loop's latch block'.
>
> With 'SimplifyCFG', I have come in a situation where a !llvm.loop is associated to
> a basicblock that is found to be a latch block for two different loops.
>
> The original annotation of one of those loops disappeared in the process.
> (See  https://www.godbolt.org/z/5r1T5e9fs  and look for the disappearing !llvm.loop !10  in BB 'do.cond')
>
>
> Then later on,  'Canonicalize natural loops' splits the latch block up, so that it now is only
> the latch block for a single loop, but the original annotation is moved to the wrong loop.

I follow the part about simplify CFG dropping information but I don't 
see how loop-simplify moves
things to the wrong loop, not to say it couldn't, latches are associated 
with loops but we annotat
e branches which are not :(

 From what I can see, the loops, identified by their headers, have the 
following annotations before
and after those two passes (https://www.godbolt.org/z/xMn8K8a6G). What 
am I missing here, do I need
more intermediate transformations?

loop            | before                   | after
do.cond         | unroll count 2           | none
for.cond        | mustprogress, no-unroll  | mustprogress, no-unroll
for.cond1       | mustprogress             | mustprogress


>
> Questions:
> - The branch in 'do.cond' is simplified, but I have the impression that at the same time, the loop annotation is omitted.
>    This sounds like a bug ?

It is a "usability bug" in simplify CFG. If the surviving edge of a 
branch is the latch we could keep the annotation.
With the existing problem that latches are not tied to loops but 
branches are not.


> - Is it a correct assumption that we should not merge blocks if both have a branch instruction with a !llvm.loop annotation set ?

I doubt this is a viable option, too many places to check a non-trivial 
condition that is control flow dependent.
Instead, I think we might want to rethink the entire latch association 
concept. Headers are unique, they have unique
terminators, maybe we should use those to avoid the situation in which 
one branch defines two latches. That said, I'd
need to go back to the original introduction of the metadata to 
determine why latches were chosen over "headers".

~ Johannes


> Thanks,
>
> Jeroen Dobbelaere
>   
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev