[llvm-dev] PlaceSafepoints, operand bundles, and RewriteStatepointsForGC

[Joseph Tremoulet via llvm-dev]

Also, the code we need for this has now been checked in to LLILC.  Good to go.

Thanks
-Joseph

-----Original Message-----
From: Swaroop Sridhar 
Sent: Wednesday, January 27, 2016 6:33 PM
To: Pat Gavlin <pagavlin at microsoft.com>; Sanjoy Das <sanjoy at playingwithpointers.com>; llvm-dev <llvm-dev at lists.llvm.org>; Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers <andya at microsoft.com>; Russell Hadley <rhadley at microsoft.com>; Philip Reames <listmail at philipreames.com>; Manuel Jacob <me at manueljacob.de>
Subject: RE: PlaceSafepoints, operand bundles, and RewriteStatepointsForGC

I agree with Pat too, about making the change.
Using gc-transition bundles on calls is cleaner layering than eagerly emitting statepoint calls.

Swaroop.

> -----Original Message-----
> From: Pat Gavlin
> Sent: Wednesday, January 27, 2016 10:09 AM
> To: Sanjoy Das <sanjoy at playingwithpointers.com>; llvm-dev <llvm- 
> dev at lists.llvm.org>; Joseph Tremoulet <jotrem at microsoft.com>; Swaroop 
> Sridhar <Swaroop.Sridhar at microsoft.com>; Andy Ayers 
> <andya at microsoft.com>; Russell Hadley <rhadley at microsoft.com>; Philip 
> Reames <listmail at philipreames.com>; Manuel Jacob <me at manueljacob.de>
> Subject: Re: PlaceSafepoints, operand bundles, and 
> RewriteStatepointsForGC
> 
> > LLILC should mostly Just Work in
> this new world, with the exception of gc transition operands -- the 
> LLILC frontend will have to denote these using "gc-transition" operand 
> bundles, and not by eagerly emitting gc.statepoint calls.  You should 
> be able to test out your changes by passing in -spp-no-statepoints and 
> -rs4gc-use-deopt- bundles to the LLVM build used in LLILC.
> 
> Thanks for the heads up. Seems straightforward enough to me.
> 
> > Please let me know once you're okay with me making the switch to
> -spp-no-statepoints and -rs4gc-use-deopt-bundles being clamped to true.
> 
> IMO you can go ahead and make this change. We may be broken against 
> ToT for a few days, but AFAIK that shouldn't block other work in 
> progress. Joe, feel free to correct me if I'm wrong :)
> 
> - Pat
> ________________________________________
> From: Sanjoy Das <sanjoy at playingwithpointers.com>
> Sent: Wednesday, January 27, 2016 9:01 AM
> To: llvm-dev; Joseph Tremoulet; Pat Gavlin; Swaroop Sridhar; Andy 
> Ayers; Russell Hadley; Philip Reames; Manuel Jacob
> Subject: PlaceSafepoints, operand bundles, and RewriteStatepointsForGC
> 
> [+CC llvm-dev this time]
> 
> Hi,
> 
> As discussed in the review thread in
> the future plan around statepoints, deopt bundles, PlaceSafepoints 
> etc. is to "constant fold" -spp-no-statepoints and -rs4gc-use-deopt-bundles to true.
> 
> We (Azul) have moved to a representation of safepoint polls, deopt 
> state etc. that enables us to do the above; and at this point I'm 
> waiting for an okay from you guys.  LLILC should mostly Just Work in 
> this new world, with the exception of gc transition operands -- the 
> LLILC frontend will have to denote these using "gc-transition" operand 
> bundles, and not by eagerly emitting gc.statepoint calls.  You should 
> be able to test out your changes by passing in -spp-no-statepoints and 
> -rs4gc-use-deopt-bundles to the LLVM build used in LLILC.
> 
> Please let me know once you're okay with me making the switch to 
> -spp-no- statepoints and -rs4gc-use-deopt-bundles being clamped to true.
> 
> -- Sanjoy