llvm dev - Jan 2016 - PlaceSafepoints, operand bundles, and RewriteStatepointsForGC

[+CC llvm-dev this time]

Hi,

As discussed in the review thread in http://reviews.llvm.org/D16439,
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

> 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%7cf1cf46adca2b4e1b89dd08d3273b9d79%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

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

On Wed, Jan 27, 2016 at 9:01 AM, Sanjoy Das
<sanjoy at playingwithpointers.com> wrote:
> [+CC llvm-dev this time]
>
> Hi,
>
> As discussed in the review thread in http://reviews.llvm.org/D16439,
> 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.
Update: this is now done.
>
> -- Sanjoy
-- Sanjoy