This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] CCP fixes
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 19 Feb 2003 14:20:09 -0700
- Subject: Re: [tree-ssa] CCP fixes
- Reply-to: law at redhat dot com
In message <1045682262 dot 3748 dot 38 dot camel at frodo>, Diego Novillo writes:
>They wouldn't be non-gimple once we tell is_simple_val() to return true
>if really_constant_p() is true (BTW, we should really do a SIMPLE ->
>GIMPLE rename). My point is that once you accept these expression trees
>into the GIMPLE grammar, passes can treat them as black boxes. No pass
>needs to look into them, they can be moved around as atomic things once
>they're declared constants.
No, it's not that simple. For example, evaluation of these constants
needs to know that (for example) an operand to a PLUS_EXPR can have an
>> My only objection to this is code which looks at operands of binary
>> expressions needs to be able to handle any arbitrary constant as an
>> operand -- at which point we start to lose one of the nicer properties
>> of GIMPLE trees.
>But you would still have a BINARY_EXPR that has two children, one (or
>both) of them is a GIMPLE val, so you don't need to worry about it
>anymore. You can treat it as an opaque constant value. Yeah, it may
>structurally be horrid, but I don't see a way of breaking it down
>without making it non-constant.
Yes you still have two children, but you have zero knowledge of the
underlying structure of those children.
>> No, it's not that simple. Once you allow those arbitrary constants, you
>> need to make sure the later passes know how to deal with the arbitrary
>> constants. Look carefully at the un-ssa pass, it makes assumptions about
>> the structure of expression operands.
>Eh? Not it doesn't. rewrite_out_of_ssa() doesn't examine expressions,
>it just rewrites the 'tree *' that get_stmt_operands() returns. We
>never re-write nodes of trees for which really_constant_p() returns
>true, do we? (/me crosses fingers).
That's what got me looking at this to begin with! ie, we had something
which passed really_constant_p, but which (due to a bug) had a
SSA_NAME inside it. The renaming code assumed that if the toplevel object
wasn't an SSA_NAME, then there was nothing to do. Thus the SSA_NAME lived
beyond the SSA optimizers and all hell broke loose after that.