On Apr 12, 2011, at 4:46 AM, Laurynas Biveinis wrote:
>> So what's the plan for the case where you need to change the lifetime of
>> an object?
>
> Copying it. Frankly at the moment I don't how much trouble does deep
> copying from scratch to function entails,
The code to copy isn't too hard and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/11 05:54, Bernd Schmidt wrote:
> On 04/11/2011 10:03 PM, Jeff Law wrote:
>> One of the fundamental problems you have to watch out for when dealing
>> with scratch objects is how to handle the case when you belatedly
>> realize you want the obj
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/11 02:45, Steven Bosscher wrote:
> On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek wrote:
>> On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
>>> I think all these comments from you "old guys" ;-) are more
>>> discouraging than
On 04/11/2011 10:03 PM, Jeff Law wrote:
> One of the fundamental problems you have to watch out for when dealing
> with scratch objects is how to handle the case when you belatedly
> realize you want the object to have a longer lifetime.
Historically, our problems with obstacks were a consequence
[Resending with the correct Mike's address, sorry for the spam]
> So what's the plan for the case where you need to change the lifetime of
> an object?
Copying it. Frankly at the moment I don't how much trouble does deep
copying from scratch to function entails, as mentioned in your other
e-mail.
> So what's the plan for the case where you need to change the lifetime of
> an object?
Copying it. Frankly at the moment I don't how much trouble does deep
copying from scratch to function entails, as mentioned in your other
e-mail. ATM I am working at separating permanent from function. If it
tu
On Tue, Apr 12, 2011 at 12:44 PM, Mike Stump wrote:
>> - If objects stored in PCH have pointers pointing outside of
>> PCH-able/GC-managed memory, these become wild pointers on PCH read even with
>> GTY((skip)) applied properly. However, not all GTY((skip)) pointers point
>> outside of PCH-ab
On Apr 12, 2011, at 1:45 AM, Steven Bosscher wrote:
> On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek wrote:
>> On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
>>> I think all these comments from you "old guys" ;-) are more
>>> discouraging than fair. What Laurynas and Bernd have d
On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek wrote:
> On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
>> I think all these comments from you "old guys" ;-) are more
>> discouraging than fair. What Laurynas and Bernd have done, is nothing
>
> It is IMHO completely fair to point t
On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
> I think all these comments from you "old guys" ;-) are more
> discouraging than fair. What Laurynas and Bernd have done, is nothing
It is IMHO completely fair to point that the risks this brings in
a huge maintainance nightmare are
On Tue, Apr 12, 2011 at 4:54 AM, Jeff Law wrote:
> On 04/11/11 18:21, Mike Stump wrote:
>> On Apr 11, 2011, at 1:03 PM, Jeff Law wrote:
>>> The obvious solution is you copy the object, but then you have to be
>>> able to distinguish within the object, what fields point to other
>>> temporary objec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/11/11 18:21, Mike Stump wrote:
> On Apr 11, 2011, at 1:03 PM, Jeff Law wrote:
>> The obvious solution is you copy the object, but then you have to be
>> able to distinguish within the object, what fields point to other
>> temporary objects vs per
On Apr 11, 2011, at 1:03 PM, Jeff Law wrote:
> The obvious solution is you copy the object, but then you have to be
> able to distinguish within the object, what fields point to other
> temporary objects vs permanent objects so that you can copy the
> referenced temporary objects, but not the perma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/10/11 12:22, Laurynas Biveinis wrote:
>
> It is certainly true that moving away from GC will make some kinds of
> bugs possible again, but I hope that not enough to be an unmanageable
> concern.
It's definitely a huge concern. More for tree obj
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/10/11 12:27, Laurynas Biveinis wrote:
> 2011/4/9 Steven Bosscher :
>> 4. RTL per function. GCC expands one GIMPLE function at a time, and
>> the idea is to initialize the RTL obstack once when expanding starts,
>> let it grow until final, and blo
On Sun, Apr 10, 2011 at 8:22 PM, Laurynas Biveinis
wrote:
> It is certainly true that moving away from GC will make some kinds of
> bugs possible again, but I hope that not enough to be an unmanageable
> concern.
One thing that may help, is to poison parts of released obstacks,
instead of actuall
On Sun, 10 Apr 2011 21:27:10 +0300
Laurynas Biveinis wrote:
> 2011/4/9 Steven Bosscher :
> > 4. RTL per function. GCC expands one GIMPLE function at a time, and
> > the idea is to initialize the RTL obstack once when expanding starts,
> > let it grow until final, and blow it away after final. Unl
2011/4/9 Steven Bosscher :
> 4. RTL per function. GCC expands one GIMPLE function at a time, and
> the idea is to initialize the RTL obstack once when expanding starts,
> let it grow until final, and blow it away after final. Unlike 20 years
> ago, this obstack is never rolled back during RTL passe
2011/4/8 Jeff Law :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/08/11 07:21, Laurynas Biveinis wrote:
>> 2011/4/8 Steven Bosscher :
* stmt.c (label_rtx): Allocate RTX in permanent RTL memory.
>>>
>>> That looks strange, labels should be function specific, except
>>> non-
On Fri, Apr 8, 2011 at 4:36 PM, Jeff Law wrote:
>>> Perhaps a third, per-translation-unit obstack is necessary?
>>
>> Perhaps. After I finish with permanent rtl obstack, I will measure how
>> large it gets and if it's worthwhile to split out
>> per-translation-obstack out of it.
> And then you'll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/08/11 08:39, Richard Guenther wrote:
> On Fri, Apr 8, 2011 at 4:36 PM, Jeff Law wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 04/08/11 07:21, Laurynas Biveinis wrote:
>>> 2011/4/8 Steven Bosscher :
>* stmt.c (la
On Fri, Apr 8, 2011 at 4:36 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/08/11 07:21, Laurynas Biveinis wrote:
>> 2011/4/8 Steven Bosscher :
* stmt.c (label_rtx): Allocate RTX in permanent RTL memory.
>>>
>>> That looks strange, labels should be funct
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/08/11 07:21, Laurynas Biveinis wrote:
> 2011/4/8 Steven Bosscher :
>>>* stmt.c (label_rtx): Allocate RTX in permanent RTL memory.
>>
>> That looks strange, labels should be function specific, except
>> non-local labels. Maybe you can get
2011/4/8 Steven Bosscher :
>> * stmt.c (label_rtx): Allocate RTX in permanent RTL memory.
>
> That looks strange, labels should be function specific, except
> non-local labels. Maybe you can get away with allocating DECL_NONLOCAL
> labels on the permanent rtl obstack?
That's a good idea, I
On Thu, Apr 7, 2011 at 8:17 AM, Laurynas Biveinis
wrote:
> Fixes a bunch of C testsuite failures. Committed to gc-improv.
>
> 2011-04-07 Laurynas Biveinis
>
> * stmt.c (label_rtx): Allocate RTX in permanent RTL memory.
That looks strange, labels should be function specific, except
non-l
Fixes a bunch of C testsuite failures. Committed to gc-improv.
2011-04-07 Laurynas Biveinis
* stmt.c (label_rtx): Allocate RTX in permanent RTL memory.
Index: stmt.c
===
--- stmt.c (revision 170593)
+++ stmt.c (working cop
26 matches
Mail list logo
