Richard Guenther wrote:
On Mon, Oct 13, 2008 at 7:23 AM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
Hello All,
Andrew Pinski wrote:
On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
Hello All,
I am sometimes wishing to be able to scan some few local variables in GCC
garbage collector, GGC.
The only time I can think of when you want to do that is when the pass
creates lots of garbage. The only pass I can think of that might
cause that much garbage is the inliner but even then it would only be
make stuff dead rather than creating new data structures which are
dead.
Can you give a more concrete example of why you want this?
Yes, the MELT branch. There is some incomplete documentation on the wiki,
and in the MELT branch itself, file gcc/doc/melt.texi.
[...]
In addition, I also do think that a ggc_collect_with_local would be useful
to plugins.
It looks like the MELT scheme of garbage collection is simply incompatible
with the GCC one. And I don't see a reason to complicate GCC GGC by
introducing a possibility to scan the stack (you would have to register all
stack objects as (temporary) roots, otherwise GGCs precise nature would
break).
I'm not sure to understand the meaning of "MELT GC being incompatible
with GGC one". On the contrary, it is designed to be compatible, it is
compatble in practice, and it works quite well.
The point is how should MELT handle unboxed GCC stuff (like gimple_seq
gimple tree edge ...etc...) which is allocated inside MELT code.
If an ggc_collect_with_local scheme is not possible (but I repeat that I
find it simpler, more efficient, and even perhaps more elegant), I have
always the possibility of having static vectors for every such type of
stuff (ie one vector of gimple, another of gimple_seq, another of
tree-s, and so forth) and generate code which pushes value there.
Generating code which directly marks (in the GGC collector) stuff would
be simpler [this means a solution like the ggc_collect_with_local I just
suggested], but I can do without. By the way, the
So my perception is on the contrary that MELT GC is fully compatible
with GGC (and this is expected, since MELT was *designed* for
compatibility with GCC internals; in other words, compatibility with GGC
is a major design goal of MELT.), so I feel a little surprised by your
"imcompatible" wording, probably because I did not explain MELT well enough.
My only question was how to make MELT even more compatible for stuff
allocated in MELT code (this does not yet happen in practice, but it
could in the future, so it is not my topmost priority for now). So if a
ggc_collect_with_local is not acceptable (ie patching a bit ggc.c) when
GCC goes back in stage1 I could live without (using the static vector
tricks I suggested above). But again, such a solution is simpler to me,
and I believe it could help plugins.
> otherwise GGCs precise nature would break).
Strico sensu, GGC is not precise enough, precisely (sorry for the poor
pun on words) because it does not handle at all any local pointers. So I
won't describe GGC as a precise collector, only as a garbage collector
precise for global data, and ignoring all local data. This makes a huge
difference to everyone using GGC, and every GGC user has to be aware of
this fact (which is documented).
Regards.
PS. English is not a native language for me, so excuse my approximate
language.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
