Re: [PATCH] Remove bogus TYPE_IS_SIZETYPE special-casing in extract_muldiv_1

[Richard Guenther <richard.guenther@gmail.com>]

On Sat, Sep 3, 2011 at 9:47 PM, Richard Kenner
<kenner@vlsi1.ultra.nyu.edu> wrote:
> Let me jump in on this a little bit, since much of the code in this area
> was originally written by me.
>
>> Are all sizetype (sub-)expressions always of value in that range?
>> What do we do about the fact that sizetype is unsigned, so -x always
>> overflows for x != 0?  Thus, do we need to disable all a - b -> a +
>> -b kind of foldings for sizetypes? (we don't)
>
> The basic idea is that an overflow of sizetype is either:
>
> (1) Detected at a higher level (e.g., testing for maximum sizes of objects) or;
> (2) Is an undetected error and hence the result of such overflow is undefined.
>
> What this means from a practical point of view (but indeed a bit hard
> to define from a formal point of view) is that the normal addition and
> subtraction operations (on a 2's complement machines, which all are
> now) will "do the right thing" in all cases so we can perform all
> those sorts of folding operations.

So what's your opinion on the "bug" that triggered the patch in question?\
Namely extract_muldiv_1 folding

(((10240 - (sizetype) first) + 1) * 8) /[cl] 8

to

((sizetype) first * 0x0fffffffffffffff8 + 81928) /[cl] 8

to

((sizetype) first * 2305843009213693951 + 10241)

thus, folding A - B to -B + A, which is valid for unsigned types only
if overflow wraps.  But the 2nd folding is only valid if overflow is undefined.
Both foldings happen in extract_muldiv_1, the latter is especially
enabled for TYPE_IS_SIZETYPE.

The reasoning why both transforms are valid is bogus IMHO.
Can you give a formal definition of sizetype behavior that can be
used to prove that both transforms are valid?

Richard.