This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: tree_ssa_useless_type_conversions
> In message <20031106174726.GT13705@kam.mff.cuni.cz>, Jan Hubicka writes:
> >Hi,
> >I run into problems with operations having different types as operands
> >(similar to one causing string-opt failures I just fixed). These seems
> >to be commig from the fact that phi nodes already does have such a wrong
> >types after dominator optimizations because of
> >tree_ssa_useless_type_conversion
> >
> >What is our expected behaviour here? Should simplifiers/expanders deal
> >with such a type differences or should we always care to re-invent the
> >nop?
> Can you be more specific?
>
> tree_ssa_useless_type_conversion is designed to flag totally pointless
> type conversions. If it's removing something that the simplifiers or
> expanders need, then we need to look closely at the code in question
> to determine what the right course of action would be.
I've added simple type checking into GIMPLE after noticing that wrong
types produced by string builtins caused the long lasting failures.
I originally simply tested that types of operands of PHI nodes match the
destination and similarly checked binary operands in
fold_binary_nondestructive.
This turned out to fire. After ssa-dom pass we already do have
unmatched types in PHI nodes, while later these gets propagated into
actual instructions by copy propagation.
I am having problem to think of how to do type checking in such a
relaxed typing system. Gimple specifies that types must match. If I
write tree_ssa_types_compatible_p predicate that duplicate the code of
useless_type_conversion, I run into proplem that the function is not
transitive nor symmetric and thus we do not produce equivalence classes.
We may change type twice, both times doing allowed useless conversion
and end up with non-useless conversion.
Honza
>
> Jeff
>
>
>
>