llvm dev - Jul 2021 - Address of instruction in codegen

Reid Kleckner <rnk at google.com> writes:
> A word of caution: depending on where you are in codegen, there are late
> passes that can delete or duplicate MachineInstrs (tail duplication comes
> to mind). You need to be reasonably confident that the annotated
> instruction won't be affected by such passes, or you will get errors
from
> the assembler about an undefined label or duplicate label definitions.
I actually ran into that.  :)  Would a patch to fix the tail merging
issue be of interest?  As composed now I have it not allowing merging
where a pre- or post-symbol differs but I can also imagine enhancements
to update uses of the symbol.

                        -David

On Wed, Jul 7, 2021 at 7:40 PM David Greene <dag at obbligato.org> wrote:
> Reid Kleckner <rnk at google.com> writes:
>
> > A word of caution: depending on where you are in codegen, there are
late
> > passes that can delete or duplicate MachineInstrs (tail duplication
comes
> > to mind). You need to be reasonably confident that the annotated
> > instruction won't be affected by such passes, or you will get
errors from
> > the assembler about an undefined label or duplicate label definitions.
>
> I actually ran into that.  :)  Would a patch to fix the tail merging
> issue be of interest?  As composed now I have it not allowing merging
> where a pre- or post-symbol differs but I can also imagine enhancements
> to update uses of the symbol.
>
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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210707/8935c2ef/attachment.html>