llvm dev - Apr 2021 - SimplifyCFG, llvm.loop and latch blocks

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.


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

Thanks,

Jeroen Dobbelaere

I think that metadata / annotation preservation isn't perfect and is on a
best-effort basis in general, unfortunately, as the IR spec may say that
it's okay to drop them. But contributions would be welcome to improve it.

On Wed, Apr 7, 2021 at 10:17 AM Jeroen Dobbelaere via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
>
> 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 ?
> - Is it a correct assumption that we should not merge blocks if both have
> a branch instruction with a !llvm.loop annotation set ?
>
> Thanks,
>
> Jeroen Dobbelaere
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210408/d4b59741/attachment.html>

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