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

[law at redhat dot com]

In message <20040106162146.GI6383@kam.mff.cuni.cz>, Jan Hubicka writes:
 >>   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.
 >
 >We are currently feeding folders and expanders by expressions whithout
 >these useless NOPS, how it is different then?
This is why I said the #1 thing we have to decide is how strict do we want
to be regarding types of operands within expressions.  If we go with an
absolutely strict system, then we need to rethink how we deal with
type conversions in the optimizers.  If we go with a looser system, then
we need to figure out how to deal with it sanely within the checkers
and the expanders.

 >>  >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.
 >
 >How you want to make single folder do magically what you want?
There's going to be a set of transformations which are totally independent
of the language as well as whether or not we are dealing with gimple.

Languages will probably need to add callbacks or flags for additional folding
that is allowed by the language.  Similarly for testing whether or not the
result is a valid expression (we don't want to be creating SAVE_EXPRs 
once the code is gimplified).

jeff