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

[Andrew Trick]

On Feb 27, 2014, at 5:04 PM, Philip Reames <listmail at philipreames.com> wrote:

> 
> 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.

OK. That’s what foldPatchpoint was supposed to handle. We can handle stackmap/patchpoint with more than NumPhysRegs live values. Note that the call arguments are handled differently and must follow the calling convention that you choose—these are not foldable but may be passed on the stack.

>> 
>> 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.

I think you mean whichever register we happen to allocate for the live value (root ptr in your case) may be updated. This is the major difference between your safepoints and current patchpoints, and the main feature that enables fully moving GC.

You might need to have an implicit def for each live value use and mark it as “tied” to the use. I’m not sure we can handle tied implicit defs as opposed to tied normal defs. I don’t think it’s ever been done. It could require tinkering with some nasty areas of TwoAddress,  RegisterCoalescer, and RegAlloc.

-Andy

> 
> Philip