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


In message <1045622863 dot 2027 dot 35 dot camel at frodo>, Diego Novillo writes:
 >On Tue, 2003-02-18 at 15:05, law at redhat dot com wrote:
 >
 >> The second is more interesting.  CCP was creating non-gimple trees.
 >> 
 >Yes, we had this discussion last year.  I initially had CCP not generate
 >non-gimple trees, but then I figured since the trees cause
 >really_constant_p() to return true, we should let it do the
 >replacement.  What we really need is the builtin expanders to be smarter
 >(we currently fail string-opt-8.c for this reason).
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.


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

 >> While I haven't tried to construct a testcase where the compiler would
 >> fault, it seems *extremely* bad to me to allow CCP to change a tree
 >> from gimple form into non-gimple form.
 >> 
 >All we need to do is accept in is_simple_val any tree that causes
 >really_constant_p() to return true.  Things like &b - &a really are
 >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.

Jeff


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