Re: [patch] Introduce deep unsharing

[Richard Guenther <richard dot guenther at gmail dot com>]

On Sat, May 15, 2010 at 12:13 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Hm, but then we modify trees that are visible elsewhere, correct?
>
> No, because we unshare them first in each function.

"unshare" == make local copies of global types in each function
that uses them?  (and thus never actually use the global type?)

It'll have interesting effects on TBAA if you inline one of those
functions into another I guess?

If you don't end up copying the types themselves I still don't see
how copying anything else will avoid gimplification of one function
affecting that of another.

So, if in discr23.adb you add a wrapper function around the
function that uses the global type, like in pseudo-C (I don't
grok the Ada in that testcase at all ...)

struct X {
  int len;
  char string[len];
};

struct X foo (struct X x) { return x; }
struct X bar (...) { struct X x; return foo(x); }

how does the gimplification process work?  I assume that if we start at foo()
we do

 1) copy the type X, gimplify it and replace all uses of the original type (?)
 2) repeat the same for bar

?

If we don't copy the types then its sizes get gimplified in the first
function and TYPE_SIZES_GIMPLIFIED gets set on the type.
When we arrive at the 2nd function no matter if we copy anything
in the type itself TYPE_SIZES_GIMPLIFIED is still set and the
type sizes are replaced.  If you otoh avoid gimplifying the type sizes
then you won't get them gimplified.

So maybe you don't want to gimplify type sizes but only gimplify
references to them inside COMPONENT_REFs and ARRAY_REFs?
And those are all via SAVE_EXPRs that are shared between
expressions across functions?   So you'd need to copy the SAVE_EXPR
itself before gimplifying it?  At least I don't see how only copying
its argument is going to help you - the SAVE_EXPR itself will still
be shared and you modify all shared uses.

So - I'm still confused.

Richard.

>> I can't really see how gimplifying type-sizes of global types would work
>> multiple times.
>
> We don't really gimplify them since we cannot, as gimplifying means creating
> temporaries and therefore requires a function. ?Instead we arrange to have
> them unshared in each function and the result gimplified there.
>
>> Correct. ?Your patch is certainly a no-op for all languages but Ada,
>> but as we gimplify unit-at-a-time can't you do the necessary unsharing
>> from inside the frontend? ?I obviously miss something (and I will have a
>> look at the testcase and its dumps next week).
>
> Yes, but this would essentially mean duplicating what is already done in the
> gimplifier more robustly. ?And other front-ends would have to reimplement it.
>
> I can add a big comment in langhooks.h explaining what deep_unsharing is used
> for and the strategy implemented to support global types with variable size.
>
> --
> Eric Botcazou
>