[PATCH] Dispose of non-gimplifier users of is_gimple_tmp_var
Tue Aug 17 21:14:00 GMT 2004
Jason Merrill wrote:
> On Mon, 16 Aug 2004 11:07:59 -0400, Nathanael Nerode <firstname.lastname@example.org> wrote:
>>Jason Merrill wrote:
>>>On Mon, 16 Aug 2004 09:19:21 -0400, email@example.com (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
> 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.
The use seems to be actually to handle a certain type of situation:
when we want to break
X = Y;
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. :-(
More information about the Gcc-patches