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

[law at redhat dot com]

In message <Pine.LNX.4.44.0312222046060.26239-100000@www.eyesopen.com>, Roger S
ayle writes:
 >
 >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.
This is probably the first thing we need to settle on.  Should 
expressions such as PLUS_EXPR, MODIFY_EXPR, etc require that both types
be identical?

  From a cleanliness standpoint that has a lot of very nice properties
  (among them there's never any question about if an expression is
  valid if its types don't match (with the exception of NOP_EXPR and
  CONVERT_EXPR).  And my gut tells me it's ultimately the right thing to
  do.

  It does get in the way of some optimizations.  Relaxing that rule to
  allow type mismatches if the main variants are the same, or in certain
  cases where the type conversion is known to not affect the result would
  be easier for the optimizers, but not as clean.  It's also the case that
  the optimizers are getting better at "seeing through" the useless
  type conversions.

 >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.
It could also be the tree-ssa code playing it fast and loose with types.
I've found a couple of these that I've introduced and later fixed in the
dominator optimizer.  I wouldn't be terribly surprised if I goof'd this
in other places.

 >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.
Well, if the result doesn't match the passed-in type, then the caller is
probably going to convert it anyway -- if it doesn't then the caller is
probably buggy.

I suspect there are callers that would need to be updated regardless
of which path we choose.  If fold always converts, then it means the
optimizers need to get even better at seeing through conversions, but
it's not the end of the world.


 >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.
Most definitely.

jeffk