Re: [tree-ssa] where to fix this?

[law at redhat dot com]

In message <20031223122751.GA2181@atrey.karlin.mff.cuni.cz>, Jan Hubicka writes
:
 >> My personal opinion is that constant folding should preserve the
 >> type correctness of its transformations, calling "convert" on its
 >> result if ever in doubt.  Unfortunately I think this is controversial,
 >> with Jan arguing that this introduces so-called useless type conversions
 >
 >Actually it was not me arguing for this idea,  I was just trying to
 >understand Jeff's plans in this area.  I was bit surprised by
 >introducing the notion of useless type conversions, but I don't have
 >very strong reasons for deciding about whether it is great idea or way
 >to disaster :) I guess we will work out.
Why would it be a surprise?  Some type conversions are strictly for the
benefit of code which wants both operands of an expression to have precisely
the same type.

However, there are a *ton* of cases where those type conversions are absolutely
meaningless to the optimizers and code generators and in fact those
conversions get in the way of optimizing code well because they hide
equivalences.  

ie, if I have something like

x = (type) y;

If we can prove that the typecast is useless, then we can enter x = y into
the const_and_copies table and copy propagate y into the uses of x.  Often
this also makes "x" go away completely.

If you want to see how bad this is, get some code, say any file from GCC,
compile it once with the tree-ssa branch unmodified and dump the RTL code
via -dr.  Then disable the useless type conversion code, compile it again
and compare the dump files.  You'll be rather amazed.

I've said it before and I'll say it again, we need a better designed
scheme for dealing with type conversions and whatever we choose needs to
be fully documented.

 >Actually I think we are in the sync here.  I also think in favour of
 >making convert to not produce NOP expr at all for useless type
 >conversions.
Sigh, you're still missing some fundamental issues here.

  1. You often can not tell if a given typecast is useless without some
     additional context.

  2. If you have convert not emit useless type conversions, then you have
     to fix all the expanders and all the folders to handle operands which
     may have different types.
     

 >Unfortunately there are some cases where this holds for GIMPLE too.  You
 >may see folding fix 6 I sent recently.  The SWITCH_EXPR of enum type
 >must be represented as SWITCH_EXPR containign NOP to integer type
 >containing enum type as switch expander would otherwise asume that not
 >all integer values are possible.
FYI, Richard may have just fixed this problem.


 >Concerning the fold/convert interface, I think that we ought to have
 >fold/convert for GIMPLE that inputs gimple RHS expressions and produce
 >them but it is still not clear to me how to share the pattern matching
 >with C/C++ version of fold and how to reuse existing implementation.
 >
 >I still seem to think that easiest approach may be to first implement
 >brand new folder for C/C++ that uses exactly transformations specified
 >in the standard.  This will solve age old problems where we are
 >accepting more complex constant experssions than we ought to and should
 >not be at all that much work.
 >
 >Then we can move whole existing fold into GIMPLE, strip out
 >transformations that require nested trees and thus won't match on GIMPLE
 >directly and re-implement them using walking the SSA graph as part of
 >some expression reshaping passs.
As has been stated before, fold needs a complete redesign.  And I really
would prefer to have a single folder, not a gimple folder, then a 
arbitrary tree folder, then language specific folders.  Ick.

jeff

Jeff