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

[Philip Reames]

On 02/27/2014 02:49 PM, Andrew Trick wrote:
> On Feb 25, 2014, at 5:32 PM, Philip Reames <listmail at philipreames.com> wrote:
>> 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 can go ahead and hack the folding code to unconditionally fold into SAFEPOINTs and move the load after the SAFEPOINT, but that feels like an utter hack.  Before going down the road, does anyone have a better suggestion?
> Anything we do to avoid the reload is purely an optimization. There is no way to guarantee it. I think you really need your pseudo instruction to include the call, which is exactly what patchpoint was designed for.
I'm probably going to move in that direction, but even with the 
patchpoint implementation this isn't strictly true.

If my stack map has more arguments than physical registers, it's 
mandatory that the patchpoint not require a load.  Since writing my 
original email, I think I've figured out how to address this in the 
register allocator.  I'll try to clean this up and send a patch.

Consider the following pseudo code:
(ptr1, ..., ptr200) = initialize_pointers();
call some_function() // safepoint needed here
use(ptr1, ..., ptr200) //more than one use to prevent folding

I'm not entirely sure the above applies to the patchpoint 
implementation.  I know it definitely applied to my previous approach.  
I'll try to create a test case using only patchpoint and share it.

>
> That said, it would be nice to be more aggressive in folding reloads into stackmaps/patchpoints. It sounds like you are already making use of the foldPatchPoint logic that I added to avoid the reloads. We just need some higher level logic to handle more cases. I’m not sure how hard it will be. See InlineSpiller::foldMemoryOperand.
If you have suggestions for specific missing cases, let me know.

p.s. I'll need to extend PATCHPOINT semantics in at least minor ways.  
Every argument is both readable and *writeable*.  This is different than 
the existing intrinsics.

Philip