[PATCH] Dispose of non-gimplifier users of is_gimple_tmp_var

Nathanael Nerode neroden@fastmail.fm
Tue Aug 17 21:14:00 GMT 2004


Jason Merrill wrote:
> 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.
Well.... maybe.

The use seems to be actually to handle a certain type of situation:
when we want to break
X = Y;
into
tmp = Y;
X = tmp;
for certain types of X (what types?)
but we *don't* want to recurse and create an infinite number of temporaries.
This isn't exactly normal SSA work.

The big question here is *exactly* what types of X we want to force 
temporaries for.  Currently we are *not* forcing temporaries for certain 
front-end artificial variables where we should.

Case 1 is where the RHS may throw.  Here the requirement appears to be 
as Kenner described, i.e. the LHS var is TREE_READONLY.  (And we may 
have to set it in more places.)
Case 2 I couldn't decipher and has something to do with 
is_gimple_mem_rhs.  It may be the same requirement, or it may not.  :-P

> 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?

Frankly I'm not sure exactly what to do; others might have a better 
idea.  I want it to make rhs_predicate_for behave correctly, but I'm not 
100% sure what "correct" is in this case.  I've been trying to figure 
this out.  :-)

> 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.
Hmm.  That doesn't seem right either, actually.  :-(

> Jason



More information about the Gcc-patches mailing list