Re: Meaning of TREE_ADDRESSABLE types (Was: [PATCH] Fix PR40389)

[Richard Guenther <rguenther at suse dot de>]

On Tue, 16 Jun 2009, Jakub Jelinek wrote:

> On Tue, Jun 16, 2009 at 11:21:18AM +0200, Richard Guenther wrote:
> > On Tue, 16 Jun 2009, Martin Jambor wrote:
> > 
> > > On Mon, Jun 15, 2009 at 04:12:16PM +0200, Richard Guenther wrote:
> > > > This is a variant for the 4.4 branch.  If we can settle on
> > > > testing TREE_ADDRESSABLE on the object, not the type (or if somebody
> > > > can explain me what TREE_ADDRESSABLE on types semantically means
> > > > for the middle-end and how this relates to the failure mode).
> > > > 
> > > 
> > > I have pondered  over this too.  As far as  I understand it correctly,
> > > the flag is  overloaded, has nothing to do  with addressability of the
> > > instances of the  type and the comment in  tree.h is wrong.  Certainly
> > > SRA has to  be able to split  them or we get very  poor performance in
> > > C++.
> > > 
> > > Instead, what it (again, IIUC) means  is that the instances have to be
> > > somehow specially constructed when created.  In middle end that has at
> > > least one important consequence,  we cannot create temporary variables
> > > of these  types (either directly or  through force_gimple_operand, for
> > > example).
> > 
> > Ok, this sort-of was my understanding as well.  But I do not see
> > how this is connected to the NRV issue at all - certainly if NRV
> > is applied the caller can take the address of the return slot if
> > the language standard says that is a valid thing to do.  Now the
> > question is if that is only valid for 1) C++, 2) these kind of
> > special types.
> > 
> > ?
> 
> Taking address of a temporary and remembering it from callee to caller when
> passed by invisible reference, if it doesn't have TREE_ADDRESSABLE type, is
> quite fuzzy, at least I don't see how a valid program could do it.
> The problem is that if the temporary doesn't have a non-trivial destructor
> (I believe non-trivial destructor implies TREE_ADDRESSABLE type), the code
> has no way to know when the temporary goes out of scope in the caller and
> thus can't stop remembering its address at that point.

Hm, that makes sense - at least for C++.  Do other languages that can
have NRV applied also properly set TREE_ADDRESSABLE on all types this
can happen (I am thinking of Java and Ada here)?  Or shall we just
not bother until they throw a testcase at us?

Thanks,
Richard.