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

[Jan Hubicka <jh at suse dot cz>]

> In message <20040106204148.GA378@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >> In message <20040106184856.GM6383@kam.mff.cuni.cz>, Jan Hubicka writes:
>  >>  >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.
>  >> There's certainly times when I'm going to want to give fold a fairly
>  >> complex expression, but I'm going to want to know if the result of folding
>  >> that complex non-gimple expression results in a gimple expression.  That
>  >> can either be done in all the callers or it can be controlled by passing
>  >> a flag/callback to the folder.
>  >
>  >Hmm, this seems to be good argument why the idea of replacing all
>  >complex folders by special purpose pass walking SSA graph won't work
>  >very well. Uh oh.
>  >Certainnly I can imagine cases where one would need such symbolic
>  >simplification for loop optimization (we do that on RTL level for IV
>  >discovery and counting number of iterations, Pop's code seems to be
>  >doing same thing), but where we need it right now?
> When we follow def-use chains in the dominator optimizer to reassociate
> and simplify operands.  The stuff we do right now is pretty simple, but
> it's one of the two areas of the dominator optimizer that I do expect
> will need to be extended.
> 
> Consider a tree combiner.

Tree combiner and folder being able to walk SSA graph is essentially the
same thing and it seems to be sane to integrate it into dominator walk.
We need some dataflow information to be propagated (we do have value
ranges and nonzeroness in dominator optimizations, while folders attempt
to propagate some other info like lengths of strings and combiner has a
lot of use for nonzero bits....
It would be nice to manage to get this shared.

Perhaps we can export the callbacks out of tree-ssa-dom.c so all the
complex stuff don't need to go into same file and the interfaces gets
more explicit.
> 
>  >>  >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.
>  >> The callback is set up by the front-end to call a front-end routine.
>  >
>  >Yes, but what is unclear to me is how the front-end routine would look
>  >like...
> Err, the same as fold does, except that it deals with the language
> specific cases that fold can't.  Or as I've mentioned the folder's

So you mean that the callback will actually implement extra language
specific folding?
I was refering more to things like that fabs (a)<-1 is not a constant
expression in C, but GCC mistakely accept it as it's folder is too
smart.  For purposes of parsing we need to somehow disable this
smartness.

Honza
> behavior may simply be conditionalized based on arguments passed into
> it rather than callbacks.
> jeff
>