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

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 22 Dec 2003, Dale Johannesen wrote:
> >>>> I have a case where tree-ssa is calling fold() on this:
> >>>>
> >>>> <plus_expr 0x9c80a0
> >>>>     type <integer_type 0x40d42528 int SI
> >>>>         size <integer_cst 0x8e4780 constant invariant 32>
> >>>>         unit size <integer_cst 0x8e4798 constant invariant 4>...
> >>>>     invariant
> >>>>     arg 0 <integer_cst 0x40d40570 type <boolean_type 0x40d427f8
> >>>> _Bool>
> >>>> constant invariant 1>
> >>>>     arg 1 <integer_cst 0x97eed0 type <integer_type 0x40d42528 int>
> >>>> constant invariant 1>>
> >>>>
> >>>> which gets into int_const_binop, which thinks the result is _Bool
> >>>> and truncates it to 0.


My apologies for not reading this thread earlier.  The problem, as
I suspect may have already been pointed out, is that the operands of
the PLUS_EXPR don't have types matching that of the PLUS_EXPR itself.

What little semantics for trees the middle-end has, presume that
in general all operands and the result of binary operators and
non-conversion unary operators have the same type.  I'll also
acknowledge that "fold" itself is a major offender in this respect,
occassionaly returning a tree of a type different to the one it was
given; but these are bugs, to be fixed as fast as they're found.


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