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

[Jan Hubicka <jh at suse dot cz>]

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

Obivously by starting to remove useless NOPs we made step to looser
system, so I tought that this is your longer term plan.
Since we were losing the casts in fold in some cases for some time
already I would expcet that expenders should just work in this scheme,
but I am not sure how many other surprises can be here.
> 
>  >>  >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).

I don't think the idea of actually doing the folding and then testing
whether it is valid is good.  It costs memory and folder may get to be
over-active stepping out of allowed ground missing allowed
transformation as commonly happens for combine.

Also how callback "it is valid transformation according to C standard"
can be implemented?  It still has to know all the transformations C
standard mention.

So I think we will end up with some shared code controlled by flags.

How do we want to deal with transformations requiring nested expressions
in GIMPLE?  I think we must handle them there too (as incurrent scheme
when we don't match in original source expressions, we have to wait
until the trees are re-nested after whole SSA path) and I tought that it
may be implemented as part of reassocation pass.  If we do that, we may
elliminate the need to perform such a complex transformations at
generic/language trees level.  THen the folder may get much easier to
deal with than it is right now.  It would do just basic
transformations like folding constant expressions (this would need to be
paramterized for C folder), applying basic algebraic identities and
canonicalizing expressions.  That all can be probably shared across both
ILs...

Honza
> 
> jeff
> 
>