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

[Jan Hubicka <hubicka at ucw dot cz>]

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

> that are unnecessary and confuse the optimizers.  He therefore argues
> that fold shouldn't call convert.  My counter to that reasoning, is
> that this is a failure of "convert" rather than of "fold".  If convert

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.  The problem is how to set up the interfaces.  Changing
behaviour of default convert is not completely good idea for the
frontends where the NOP holds very important information for type
checking and such.  For C the useless conversions are subset of implicit
casts, but for other languages it may be very unfortunate if original
types of expressions got lost easilly.

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.

I think these are workable around.  For instance SWITCH_EXPR can have
type assigned specifying the range of input.

Overall for GIMPLE/GENERIC I am not at all sure what is the best
strategy - obviously we can either thread NOPs as usual instructions
(this is done by some compilers and it mostly works), allow easy ones as
gimple values (and get something like we do have in RTL with subregs) or
omit them.  While last one probabaly results in fastest compiler and
best code, it makes sanity checking dificult and it may make some dark
corner cases.

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

This assumes that we don't want GENERIC folder that is as strong as our
current implementation is.  Arguably we ought to be able to do all the
transformations on unnested SSA form of GIMPLE and I am not convienced
that our folder catch that many more simplification that basic C/C++
folding scheme, so perhaps this is not necessary.

Honza
> is asked to perform a "useless" type conversion it should be clever
> enough to elide the NOP_EXPR, rather than require every transformation
> in "fold" to second guess which conversions are necessary and which
> not.
> 
> 
> In short we need to work out where your boolean_true_node is coming
> from, and why we're not calling convert(integer_type_node) on it
> prior to substituting it into the addition.  It could easily be fold
> at fault, but its this missing transformation thats to blame for the
> later woes.
> 
> 
> I hope this helps,
> 
> Roger
> --