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

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>

Hi Hiroshi,

thank you for the reply.

I am aware of the general rule that Metadata can be dropped.
I am wondering if that should still hold for (at least) some of the loop
annotations.

In this particular case, there is also a 'real bug' where loop metadata
indicating that a loop
that is 'progressing but should not be unrolled' is, after some
transformations, suddenly attached to
a different, infinite loop (aka not progressing).

Greetings,

Jeroen Dobbelaere
> From: Hiroshi Yamauchi
>
> 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
<mailto: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 ?