Re: Fix wrong-code bug caused by combine_simplify_rtx()

[Paul Schlie <schlie at comcast dot net>]

> From: Richard Sandiford <rsandifo@redhat.com>
>>> No, it's not correct.  Consider s == -28:
>>> 
>>>     (signed char) (s - 100) - 5 == (signed char) -128 - 5 == -133
>>> 
>>> Your version would give 123.
>> 
>> Yup, which is correct, that's what (signed char)(-133)
> 
> No it's not.  The result is not being cast to "signed char".
> It's an "int".
> 
> Remember the usual integer promotions apply.  I.e. "(signed char) -128"
> is promoted to "int", 5 has type "int", and the result of the "-" is also
> an "int".

You're correct, I miss-read the above as: (signed char) ((s - 100) - 5)

And looking at the objective of the code, it's not clear why one would
actually want to unnecessarily extend the precision of operations deeper
into an expression than necessary, as wider operations will always tend to
be more expensive in general? (and seemingly defiantly counter productive
for operations which may be wider than the target's natural word size)

It would seem that a much better overall strategy would be to attempt to
do the opposite: i.e. try to propagate wider operations out, and narrower
operations deeper into the expression, thereby minimizing the required
precision of its sub-expressions as much as reasonably possible.