<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 6, 2020, at 17:32, Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" class="">johannesdoerfert@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Cool! I really like the idea. I left a comment about metadata preservation below.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Once this is available we will certainly employ it to understand OpenMP programs better.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div>That sounds like a great use case! Having multiple different uses cases during the bring-up would be very helpful to make sure the system is flexible enough.</div><div><br class=""><blockquote type="cite" class=""><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">We could also think about a user facing version of this while we are at it ;)</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div>Do you mean providing a way for users to add their own annotation to say C/C++ code?</div><div><br class=""></div><div>The initial patch contains a Annotation2Metadata pass, which converts Clang annotations (` __attribute__((annotate("_name”))` ) to `!annotation` metadata. This allows users to use something like the snippet below, to annotate all instructions in a function by piggybacking on Clang’s annotate attribute.</div><div><br class=""></div><span class="">void __attribute__((annotate("__overflow_rt_check"))) custom_overflow_check(int a, int b) { … }<br class=""></span><span class=""><br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""><br class="">The proposal boils down to three parts.<br class=""><br class="">The first part consists of adding a new metadata kind (!annotation ) to allow tagging of ‘interesting’ instructions. For example, Clang could add this metadata to auto-init stores it generates or a library for overflowing math could instruct Clang to add the metadata to all instructions in its overflow check functions. !annotation metadata nodes consist of a tuple containing string nodes indicating the type of the annotation.<br class=""><br class="">Using metadata comes with the drawback that it can be dropped by passes that do not know how to handle it. This means we will have to adjust existing passes to ensure the metadata is preserved for interesting instructions, if possible. I think this is the only intersection of the proposal with existing code in LLVM. Loosing the metadata for instructions is also not the end of the world. The information is provided on a best-effort basis and I am not aware of a more robust alternative to achieve the same goals.<br class=""></blockquote><br class="">I think we already have the idea of "trivially preserved" annotations and we should use that everywhere anyway.<br class=""><br class="">The method that "moves/merges" metadata should look at the annotation and decide based on the operands if<br class="">the annotation is valid for the replacement instruction or an instruction in the vicinity. If this sounds reasonable<br class="">we could use a second argument, e.g., below `!0 = !{!1, i64 BIT_ENCODING}` where the bits in BIT_ENCODING define<br class="">properties of the annotation. One could be that it is fixed to the instruction opcode, e.g., if you replace a store<br class="">with a memset you drop the annotation. Though, we would add these things on a case-by-case basis I guess.<br class=""><br class=""></blockquote><div class=""><span class=""><br class=""></span></div>That’s a good point. It would be great if we could generalize the logic to preserve the annotation metadata. I think for some transformations the `type` of the annotation does not matter, but for others it might. In those cases having a general way to encode the rules would indeed be very helpful!</span><div class=""><span class=""><br class=""></span></div><div class=""><span class="">I think Francis already took a look at some passes that would need updating when annotating auto-init stores. Most of the problematic transforms (like SROA, LoopIdiom and InstCombine) are combining stores to stores of wider types or various mem* intrinsics. As an initial general rule, it probably makes sense to preserve any annotation metadata, if all combined instructions share the same metadata?</span></div><div class=""><span class=""><br class=""></span></div><div class=""><span class="">I think it would make sense to start with something like that and then go from there and iterate once there once we have concrete use cases that need more specialized rules. What do you think?<br class=""></span></div><div class=""><span class=""><br class=""></span></div><div class=""><span class="">Cheers,</span></div><div class=""><span class="">Florian</span></div></body></html>