On Sat, Sep 3, 2011 at 10:37 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Sat, Sep 3, 2011 at 9:47 PM, Richard Kenner > <ken...@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. >
