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

[law at redhat dot com]

In message <Pine.LNX.4.44.0401061042140.1987-100000@www.eyesopen.com>, Roger Sa
yle writes:
 >
 >On Tue, 6 Jan 2004 law@redhat.com wrote:
 >> Note we can not replace the "x" inside the PLUS_EXPR with NOP_EXPR (a) sinc
 >e
 >> that would create non-gimple code, nor can we replace the "x" inside the
 >> PLUS_EXPR with "a" since that would create a PLUS_EXPR with mismatched
 >> types (and mis-matched in a bad way since width and signedness and
 >> widths of "a" and "x" are different).
 >
 >
 >Ah ok.  I'm guessing that the possible solution of allowing "no-op"
 >conversion of operands in gimple would make tree-ssa much uglier.
Considerably.  Though I keep pondering it.


 >I also presume that other SSA-based optimizers don't encounter similar
 >problems because they can represent implicit conversion of operands
 >in their tree nodes directly, i.e. PLUS_EXPR (x, y) implies implicit
 >conversion of "x" and "y" to the type of the result (or necessary type).
The typecasts primarily interfere with copy propagation, which is done
in a limited number of places.  We have copy propagation in the dominator
optimizer, then a global version in tree-ssa-ccp.c.

For something like redundancy elimination we are primarily concerned
with the type of the result (and we assume that it is compatible with
the type of the RHS expression).  We don't tend to peek at the type
of the underlying operands.  However, I don't think that ultimately we
can or should rely on that holding long term -- I can certainly see a
day when we'll want to look more closely at the operands and will need
to have the optimizer know about whatever rules we build for the type
system.

 >It might be possible to consistently switch to a weakly typed semantics
 >for GCC trees (and fold in particular),
The question in my mind is whether or not this is a good design decision.
I don't really know.  It has certainly nice properties for the optimizers,
but even with a formal definition of what mis-matches are allowed we're
likely to run into numerous "issues".

 > but there are lots of difficult
 >corner cases where the types of operands aren't unambiguously defined by
 >the type of the result. 
Right.  This has always been a major concern of mine.  In fact, my concerns
in this area have always made me quite uneasy about the whole useless
type conversion stuff I added.  


 > Indeed even defining useless-conversion has had its own share of headaches.
Yup.

 >Do you know how this is handled in other production SSA-based compilers?
Unfortunately, I don't.  It's less of an SSA issue and more of a general
optimization issue -- at what level are types exposed to the optimizers.

jeff