On Fri, Aug 21, 2009 at 5:37 AM, Steven Bosscher wrote:
> On Fri, Aug 21, 2009 at 10:52 AM, Laurynas
> Biveinis wrote:
BTW, it does not deal with types that in some instances have variables
allocated in proper GC way (with a path from GC root) and in some
instances not. Fixing these
2009/8/21 Steven Bosscher :
> Not to discourage you, but, eh... --
On the contrary, I think this is a very interesting idea.
> wouldn't it be a much more useful
> project to move RTL out of GC space completely instead of improving GC
> for rtxes? The life time of RTL is pretty well defined by no
2009/8/21 Paolo Bonzini :
>> Here tem should not be allocated on GC memory.
>
> I disagree, as this would not apply to tem only but also to anything
> allocated to fold it. This is not going to be maintainable (what if fold
> create temporary types, which need to be in GC memory definitely?).
I s
On Fri, Aug 21, 2009 at 10:52 AM, Laurynas
Biveinis wrote:
>>> BTW, it does not deal with types that in some instances have variables
>>> allocated in proper GC way (with a path from GC root) and in some
>>> instances not. Fixing these is going to be hard.
>>
>> Do you have some examples?
>
> Trees
On 08/21/2009 10:52 AM, Laurynas Biveinis wrote:
Trees and rtxes mostly. I haven't got around to taking a closer look,
but for example folders love allocating temporary trees. For example,
in tree-ssa-ccp.c:fold_gimple_assign,
if (COMPARISON_CLASS_P (op0))
{
>> BTW, it does not deal with types that in some instances have variables
>> allocated in proper GC way (with a path from GC root) and in some
>> instances not. Fixing these is going to be hard.
>
> Do you have some examples?
Trees and rtxes mostly. I haven't got around to taking a closer look,
bu
1) Stop abusing current GC by allocating structures there that GC
knows nothing about, i.e. there is never a path from GC roots to any
variables of that type and so gengtype does not produce markers it.
That's good.
BTW, it does not deal with types that in some instances have variables
alloc
