[llvm-dev] CFG manipulation and !llvm.loop metadata

[Michael Kruse via llvm-dev]

When directives such as '#pragma clang loop vectorize(enable)' were
implemented, it needed to attach its metadata somewhere, and the loop
latch was considered the most stable between passes. Strictly
speaking, LLVM metadata does not exactly match the required semantics,
since preserving metadata is just best effort, but e.g.directive such
as '#pragma omp simd' are not allowed to be just dropped. If the
compiler is not able to vectorize the loop, it should at least issue a
warning diagnostic. That is, we intend for fix all the bugs where the
loop metadata is lost.


Am Fr., 20. März 2020 um 12:48 Uhr schrieb Colin McEwan via llvm-dev
<llvm-dev at lists.llvm.org>:
>     1. Modify the framework's CFG manipulation tools to maintain the location of the !llvm.loop. A major drawback of this is that LoopInfo is needed to be able to tell whether a block is a loop latch or not (in the example of splitting a latch block's back edge, we need LoopInfo to know whether the edge we're splitting is the latch edge or exit edge) and it's not necessary available or up to date when we manipulate the CFG.

This is a good idea whenever LoopInfo is available.

If not there's still the possibility to speculatively copy the
llvm.loop to both BBs, in case a backedge is split. One of the copies
is redundant and should be ignored. I am not sure what the chance of
it to be picked up by a different loop is.

>     2. Have Loop::getLoopID() search other blocks in the loop for metadata. This has potential compile-time implications, and would change the IR language definition of the !llvm.loop as potentially existing (in a valid form) anywhere in the loop.

I don't think this is robust. The search might pick up loop metadata
intended for other loops.


>     3. Fixup utility functions for function passes to use, to search a loop and move any errant !llvm.loop to the latch block(s) of its loop.

Isn't this the same as your item 1?


> Additionally, it should probably be explicitly stated in the IR language reference that !llvm.loop preservation is best-effort and may be lost.

Feel free to create a patch and add me as a reviewer.


Michael