[llvm-dev] !llvm.loop ID metadata clarification

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 18 17:11:52 PST 2021


Our frontend (MLIR ;)) is emitting loops into LLVM IR and adding support to
emit the !loop metadatas as well:
First as an example the metadata look like this:

!1 = !{!1, !2}
!2 = !{!"llvm.loop.unroll.disable"}}

The !1 will be attached to all "latches" (back edges into the loop header)

  br i1 %exitcond, label %for.end, label %for.body, !llvm.loop !1

I'm a bit confused by a few things with this metadata at the moment. First
the self-referencing of the metadata is called out in LangRef:

> For legacy reasons, the first item of a loop metadata node must be a
reference to itself. Before the advent of the ‘distinct’ keyword, this
forced the preservation of otherwise identical metadata nodes. Since the
loop-metadata node can be attached to multiple nodes, the ‘distinct’
keyword has become unnecessary.

The last sentence isn't clear to me, I don't see the relationship between
"the loop-metadata node can be attached to multiple nodes" and "the
‘distinct’ keyword has become unnecessary"?

Also It isn't clear why we don't use a distinct metadata instead of a
self-referencing one?

Then LangRef mentions:

> Loop metadata nodes cannot be used as unique identifiers. They are
neither persistent for the same loop through transformations nor
necessarily unique to just one loop.

So the metadata itself can't be used as a unique identifier for the loop,
however in a loop all latches must have the same MDNode for LoopInfo to
recognize it as valid.

It isn't clear to me why it prevents using unique metadata here without the
self-referencing trick, and rely on content-based uniquing for equality?
Loop info could still rely on pointer-equality to ensure that the metadata
is consistent on every backedge, two loops with the same metadata would
share the same MDNode, but it shouldn't be an issue since these aren't used
as unique identifiers per LangRef.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210218/f78ea8d4/attachment.html>

More information about the llvm-dev mailing list