[patch] Introduce deep unsharing
Eric Botcazou
ebotcazou@adacore.com
Tue May 18 15:58:00 GMT 2010
> Ah, so the SAVE_EXPRs itself are not shared between functions
> but its operand is? So when the gimplifier makes its way down
> it modifies shared trees?
Yes, exactly.
> Wouldn't it be simpler (or would it be possible at all) to always
> unshare the SAVE_EXPR operand in gimplify_save_expr
> if !SAVE_EXPR_RESOLVED_P?
That should work, but this will unshare in superfluous cases (SAVE_EXPR
referenced only once in a function).
> That would avoid the pointer-map
> and I'd say we can do so unconditionally.
Doing it unconditionally (i.e. for all languages) certainly works, that's how
we do it at AdaCore, see the first submission. We also do it for TARGET_EXPR.
> Well, at least I think I do understand the problem now - do I?
Yes, very likely :-)
> I find the patch ugly because of the new langhook - it looks like
> that this either "changes" GENERIC semantics or that we
> do not properly handle what is valid GENERIC. Can you try
> enabling the unsharing by default and see how memory usage
> and compile time is affected for say C++?
Really? This stuff is totally unnecessary if you don't have global types with
non-fixed size in the language. And IMO that's orthogonal to GENERIC, it's
just an implementation artifact because we gimplify in-place; if gimplication
is ever rewritten into a regular translation phase, unsharing will be dead.
We never observed any visible impact in C or C++ with our compiler, but we
certainly don't compile much C++ with it. I can try to further experiment.
--
Eric Botcazou
More information about the Gcc-patches
mailing list