This is the mail archive of the 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

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


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