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

[Swaroop Sridhar via llvm-dev]

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
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2freviews.
> llvm.org%2fD16439%2c&data=01%7c01%7cpagavlin%40microsoft.com%7cf1c
> f46adca2b4e1b89dd08d3273b9d79%7c72f988bf86f141af91ab2d7cd011db47%
> 7c1&sdata=7aNJfJqykAmhImChq5Ww%2fiQWFEqZZCEYtPglbMCuqbc%3d
> 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