Re: [PATCH] Dispose of non-gimplifier users of is_gimple_tmp_var

[Jason Merrill <jason at redhat dot com>]

On Mon, 16 Aug 2004 11:07:59 -0400, Nathanael Nerode <neroden@fastmail.fm> wrote:

> Jason Merrill wrote:
>> On Mon, 16 Aug 2004 09:19:21 -0400, neroden@fastmail.fm (Nathanael Nerode) wrote:
>>
>>>The motivation here is that we're going to have to change the semantics
>>>of is_gimple_tmp_var and possibly break it into two or more separate
>>>functions.  Getting rid of totally spurious uses simplifies this process.
>> These are not spurious uses.  They are valid uses of the current
>> semantics.  If you want a predicate with different semantics, you should
>> give it a different name.
> No, actually, for the current actual implemented semantics, the current
> predicate already has an incorrect name.  :-)
>
> The predicate is being used in several places and they do *not* agree with
> each other on the desired semantics (what sort of artificial temporary is a
> "GIMPLE" artificial temporary).  This is, in a sense, the source of the
> problems.

Well, yes.  I agree that the predicate is being used for too many
purposes.  I think that the answer is to have two predicates, rather than
to replace some uses with an inline expansion.

I looked through the uses in the gimplifier, and it seems to me that the
use in gimplify_modify_expr is unnecessary now that we check !want_value.

The use in gimplify_save_expr could just check for a VAR_DECL.

That leaves the use in rhs_predicate_for, which determines whether or not a
variable is an appropriate LHS for a complex RHS.  It sounds like you want
to restrict this to only allowing expression (formal) temporaries.

A while back, I chose not to use an intermediate expression temporary when
assigning to a variable temporary because the extra decls seemed to slow
things down.  I would be open to reexamining that choice, but we should
be clear about the change.

If I understand correctly, Kenner is suggesting that we set TREE_READONLY
on temps allocated for expressions with TREE_SIDE_EFFECTS, since they are
only initialized once.  It's not clear to me that this adds much
information, since we'll be going into SSA form soon anyway.  And this is a
very specialized set of temporaries; is that the same set that you want
is_gimple_tmp_var to define, Nathanael?

The uses outside the gimplifier want to test for a variable that has does
not correspond to anything in the source, which is what the existing
predicate is supposed to test.  The FIXME notes that it doesn't, exactly,
which may be what is causing the Java problem.  Some DECL_ARTIFICIAL
variables are user-visible; the 'this' pointer in C++, for instance.

Jason