[LLVMdev] Representing a safepoint as an instruction in the x86 backend?

[Philip Reames]

On 02/27/2014 01:08 PM, Juergen Ributzka wrote:
> Hi Philip,
>
> wouldn’t it be easier to adapt the patchpoint intrinsic to allow it to take also a function address/global address as target argument. We are already tapping into the target-specific call lowering, so the call would be lowered exactly the same way. By doing this you don’t have to worry about anything getting inserted between your CALL and SAFEPOINT instruction. I know the GLUE flag is supposed to keep things together in the call sequence, but I think it is very fragile to rely on this.
Let me rephrase your suggestion slightly to make sure I understood it.  
You're suggesting that I replace the CALL node with a PATCHPOINT node 
which includes both the actual call arguments and the stack map 
arguments.  This could be done by extending the existing IR level 
patchpoint intrinsic, but could also be done at the SelectionDAGBuilder 
level.  This pseudo instruction would be lowered to the actual call in 
MCInstLower.

Thinking about it, I think this would work.  Originally, I'd thought 
there was an issue with distinguishing true arguments vs stack map 
arguments, but it looks like the PATCHPOINT code in recordPatchPoint 
already knows how to do that.  Was that added later?  I don't remember 
seeing this.

>   
> On Feb 25, 2014, at 5:32 PM, Philip Reames <listmail at philipreames.com> wrote:
>
>> The reason for this is that the folding logic only applies if there's a single use of the physical register.  If there's more than one use, it's assumed to be cheaper to reload than to perform two folded operations against memory.  (I don't know if this is true always, but more importantly for me, it breaks my intended semantics.)
>>
> Yes, that is true and the code would break if you remove that constraint, because it would delete the instruction without checking if there are still any uses remaining - although this should be easy to fix.
Agreed.  On both parts.
>
>> Does anyone know of a way to avoid the fold step to begin with?  I'd really like the register allocation to not give preference to register uses for this instruction.  If a virtual register is already in the stack, it shouldn't attempt to reload before this instruction. I haven't been able to find the appropriate hook for this.
> I thought Andy did something about this for patchpoints and stackmaps. Didn't we handled that in the target-specific frame index elimination?
It's incomplete.  Or at least it was when used with the scheme I 
originally described.  I'll have to see how it fits after moving to the 
CALL replacement scheme.

Philip