This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] CCP fixes


On Wed, 2003-02-19 at 13:16, law at redhat dot com wrote:

> If you allow CCP to generate non-gimple trees, then every pass after
> CCP needs to be aware of those non-gimple trees.  Right now that's just
> DCE and the ssa->normal pass.   Allowing CCP to create these things without
> making the appropriate adjustments elsewhere is just asking for long term
> trouble.
> 
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.


> 
>  >I don't have a strong opinion wrt to this failure.  But given the
>  >choice, I would rather have CCP do the conversion and expand the GIMPLE
>  >grammar to have is_simple_val() to use really_constant_p().
> 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.


> 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).


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]