Re: fold_convert question

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 15 Oct 2004, Richard Kenner wrote:
>     No, fold_convert is required to be strongly type safe by the GCC
>     middle-end.
>
> I'm confused.  I thought the rules are that GIMPLE is *not* strongly
> type safe.  We remove all conversions between compatible types.
> So the definition for GIMPLE is compatible types, not identical types.
>
>     [Likewise calling fold on a tree of type T, must always return
>     a tree of type T]
>
> Right, because "fold" is called on GENERIC, but fold_convert only on
> GIMPLE and the typing rules are different.

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.


>     Besides, the phrase "types are compatible" is purely a front-end
>     concept, that doesn't exist in the middle-end.
>
> Sure it does!  See STRIP_USELESS_TYPE_CONVERSION.
>
> The issue is the call from setup_one_parameter.  It wants to make sure
> that the argument is converted to the type of the parameter.  In the
> original GENERIC tree of the CALL_EXPR in this case, it was converted to
> that type with a VIEW_CONVERT_EXPR.  But that was stripped off because
> the types were compatible.  Then when the call was inlined, we tried to
> convert it back, but couldn't at middle-end level because it was an
> ARRAY_TYPE.
>
>     As an Ada person, I'm sure you appreciate not having fold_convert
>     impose any notion of "type compatability" on gigi's trees, other
>     than the semantics implied by the original trees themselves.
>
> Exactly the other way around: I expect the middle-end to consistently
> use the language hook that says what's compatible and what isn't.  If it's
> not going to do that, then it shouldn't trip "useless" type conversions!

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



<rant apologies="in advance">
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.
Rather than improve/fix the optimizers, it was decided more expedient
to instead corrupt the compiler's type system.  Amongst the curious
side-effects of using front-end type checking in the middle-end's
intermediate representation is that the set of transformations applied
to the same tree/function, differ depending upon which front-end is in
use.  i.e. a loop may vectorize in C++ or gfortran but not in C and
Java.  This situation, where the semantics of the type system is not
explicit in the intermediate language, will only make things difficult
once GCC pushes to "whirl"-like persistent intermediate representations.
Indeed we're already unable to perform interprocedural optimizations
between languages, even though we use the same gimple representations
for all front-ends.  <humour>Perhaps we should use/inline RTL?</humour>

I'm already disappointed that a use of lang_hooks has crept into
fold_convert.  It was orginally approved as a short-term fix (a.k.a.
hack), but when time came to remove it, people complained that it was
required for IMA!  Worse there have even been comments on the lists
about avoiding calls to fold_convert dues to the performance penalty
of this undesirable lang_hooks.types_compatible_p call!!
</rant>


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.

Roger
--