<pre>
> > Additionally, it should probably be explicitly stated in the IR
> language reference that !llvm.loop preservation is best-effort and may
> be lost.
>
> The LangRef spells out that transformations are required to drop all
> metadata they do not know how to preserve
> (https://llvm.org/docs/LangRef.html#metadata-nodes-and-metadata-
> strings). As you mentioned, some utilities know how to preserve certain
> kinds of metadata, but various places conservatively drop metadata. I
> expect we need to fix a lot of places.

I had somehow missed that text until discovering it the other day, and I'm increasingly concerned about the approach. I haven't seen many transformations that explicitly take steps to remove metadata that they don't understand. It's unclear what the scope of metadata that would have to be invalidated might be -- any instruction touched is at least easily within scope, but should a transform which modifies control flow clear the metadata of every instruction in a modified block? It will depend on the semantics implied by the metadata.

If transforms were to implement this more rigorously, it might lead to excessive loss of optimisation hint metadata, or require changes to many existing transforms, for each type of metadata that could be affected.

> A related issue is preserving debug metadata and a lot of work has gone
> into that area already. A good first step might be a verifier that
> checks if a pass drops !llvm.loop. That could look something like:
>
> 1. Create a Loopify pass that adds !llvm.loop for each loop in a
> function (similar to Debugify https://github.com/llvm/llvm-
> project/blob/f64e457cb75b61f6566de8327a1bfae498d5a296/llvm/lib/Transfor
> ms/Utils/Debugify.cpp)
> 2. Create a verifier that checks all loops have !llvm.loop metadata 3.
> Run -loopify before each transformation and the verifier afterwards 4.
> Fix issues.
>
> Passes that create new loops might need special handling (or an option
> to also automatically attach llvm.loop metadata to the new loops).

Thanks, this is similar to the path I'm considering heading down at the moment for our internal purposes.


I think it's worth considering creating an interface to handle potential changes to validity of metadata, which can be called by passes or the framework. This would keep knowledge of the continued validity of metadata in a common place rather than spread across transforms, so create a separation of concerns between IR modification and metadata validity, and would simplify enforcing constraints on any new metadata.


</pre><!--type:text--><!--{--><pre>*********** MEDIATEK Confidentiality Notice ***********
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or 
otherwise exempt from disclosure under applicable laws. It is 
intended to be conveyed only to the designated recipient(s). Any 
use, dissemination, distribution, printing, retaining or copying 
of this e-mail (including its attachments) by unintended recipient(s) 
is strictly prohibited and may be unlawful. If you are not an 
intended recipient of this e-mail, or believe that you have received 
this e-mail in error, please notify the sender immediately 
(by replying to this e-mail), delete any and all copies of this 
e-mail (including any attachments) from your system, and do not 
disclose the content of this e-mail to any other person. Thank you!
</pre><!--}-->