Re: fold_convert question

[kenner@vlsi1.ultra.nyu.edu (Richard Kenner)]

    But "fold" itself calls "fold_convert" to ensure/force a tree to a
    specified type.  i.e. fold_convert is called for both generic, gimple
    and potentially even by front-ends that don't use tree-ssa.

Hmm ...

    I agree completely that the problem is one of consistency, but I would
    argue that the bug is in (this use of) STRIP_USELESS_TYPE_CONVERSIONS.
    It's not that fold_convert is broken, but that the VIEW_CONVERT_EXPR
    shouldn't have been stripped off in the first place.   I probably wouldn't
    consider the conversion of an ARRAY_TYPE to a scalar to be useless?

It's not a conversion between arrays and scalars, but between two
ARRAY_TYPEs.  Otherwise, they wouldn't have been compartible!
(Ada says that two ARRAY_TYPEs are compatible if the component types
are compatible and the bounds are the same.)

    Indeed the fact that VIEW_CONVERT_EXPR is only used by Ada probably
    helps explain why S_U_T_C is overly aggressive in removing it.  For
    the majority of front-ends (and Ada uses) fold_convert does the right
    thing.

I added the removal of the VIEW_CONVERT_EXPR to S_U_T_C and I still believe
it should be there.

    tree_ssa_useless_type_conversion is an unfortunate hack to work around
    the fact that tree-ssa doesn't yet have a combiner pass.  Without a
    combiner, the optimization passes can only see one statement and its
    operands at a time, so the "necessary" type conversions required to
    keep operands consistent often create a "horizon affect" where
    optimization opportunities are missed due to the local nature of SSA
    form.

Perhaps, but I don't see it that way.  It's always better to keep code at any
level of representation as simple as possible.  If we have conversions that
we know aren't going to generate any code, the earlier we remove them the
better.

    If there's anything I can do to help you investigate/fix c61008a
    that avoids further degenerating the middle-end's type system, I'd
    be happy to help.  Ultimately, this might be a loosing crusade,
    but I couldn't forgive myself if I didn't try.  Worst case scenario
    of tweaking useless_type_conversions is that we miss some optimizations
    (until we get a tree-ssa combiner), but of perverting fold_convert
    is that we regress many difficult to diagnose code generation bugs.

The investigation of that failure is, to a large extent, secondary.

We have the larger problem of being careful to define what "type correctness"
means at tree level.  I previously thought it was uniformly agreed that it
means "strictly correct" in GENERIC and "compatible" (as defined by the lang
hook) in GIMPLE.  So the first question we need to answer is if that's
correct or not.

If it is, then we need to understand which of the tests fold_convert ought to
use based on when it's called.  It may well be that the bug here is in the
caller, which shouldn't be calling it if the types are already compatible.