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 10:37 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> 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?

And as you are here now, can you shed some light on the weird
decision to make sizetype TYPE_UNSIGNED but sign-extended
at the same time? ;)

Richard.

> Richard.
>