<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 7, 2021 at 7:40 PM David Greene <<a href="mailto:dag@obbligato.org">dag@obbligato.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> writes:<br>
<br>
> A word of caution: depending on where you are in codegen, there are late<br>
> passes that can delete or duplicate MachineInstrs (tail duplication comes<br>
> to mind). You need to be reasonably confident that the annotated<br>
> instruction won't be affected by such passes, or you will get errors from<br>
> the assembler about an undefined label or duplicate label definitions.<br>
<br>
I actually ran into that.  :)  Would a patch to fix the tail merging<br>
issue be of interest?  As composed now I have it not allowing merging<br>
where a pre- or post-symbol differs but I can also imagine enhancements<br>
to update uses of the symbol.<br></blockquote><div><br></div><div>You know, maybe it would be OK. Initially I was going to say, one of the existing applications is debug info to mark heap allocation call sites, and we don't want debug info to affect codegen. However, if such a call site were to be duplicated, we'd end up with assembler errors from MC, so it sort of already doesn't work. Maybe there is a better way to handle this application.</div><div><br></div><div>The other applications are marking setjmp calls for control flow guard and something in speculative load hardening, both security features where powering down control flow optimizations would be fine.</div></div></div>