[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