[llvm-dev] Address of instruction in codegen

[Diogo Sampaio via llvm-dev]

>   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.  
Indeed having the symbol uses updated would be appreciated. In our downstream side I've also did preventing tail duplication, but that did have very negative effect in multiple scores. 
  
 
  Diogo Sampaio
Senior Compiler Engineer • Kalray
Phone: 
dsampaio at kalrayinc.com • www.kalrayinc.com 
     
    Intelligent Data Processing
>From Cloud to Edge     
 . 

   

-----Original Message-----

From: Reid <llvm-dev at lists.llvm.org>
To: David <dag at obbligato.org>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Date: Thursday, 8 July 2021 4:55 AM CEST
Subject: Re: [llvm-dev] Address of instruction in codegen

     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/20210708/3478ae1d/attachment.html>