On Thu, May 19, 2011 at 3:08 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > 2011/5/19 Richard Guenther <richard.guent...@gmail.com>: >> On Thu, May 19, 2011 at 2:59 PM, Kai Tietz <ktiet...@googlemail.com> wrote: >>> 2011/5/19 Richard Guenther <richard.guent...@gmail.com>: >>>> On Thu, May 19, 2011 at 2:48 PM, Kai Tietz <ktiet...@googlemail.com> wrote: >>>>> Hello, >>>>> >>>>> This patch improves reassociation folding for comparision. It expands >>>>> expressions within binary-AND/OR expression like (X | Y) == 0 to (X == >>>>> 0 && Y == 0) >>>>> and (X | Y) != 0 to (X != 0 || Y != 0). This is necessary to allow >>>>> better reassociation >>>>> on weak pre-folded logical expressions. This unfolding gets undone >>>>> anyway later by pass, >>>>> so no disadvantage gets introduced. >>>>> Also while going through BB-list, it tries to do some little >>>>> type-sinking for SSA sequences >>>>> like "D1 = (type) bool1; D2 = (type) bool2; D3 = D1 & D2;' to 'D1 = >>>>> bool1 & bool2; D2 = (type) D1;'. >>>>> This folding has the advantage to see better through intermediate >>>>> results with none-boolean type. >>>>> The function eliminate_redundant_comparison () got reworded so, that >>>>> doesn't break in all cases. >>>>> It now continues to find duplicates and tries to find inverse variant >>>>> (folded to constant). By this >>>>> change we don't combine possible weak optimizations too fast, before >>>>> we can find and handle >>>>> inverse or duplicates. >>>> >>>> sinking casting belongs not here but instead to tree-ssa-forwprop. >>>> I'm not sure that a != 0 | b != 0 is the better canonical variant than >>>> a | b != 0 though. >>>> >>>> is_boolean_compatible_type_p looks like a strange remanent. >>>> >>>> Richard. >>> >>> Well, a | b != 0 is for sure more optimal, but for reassociation we >>> need to see the unfolded variant temporary. This is necessary as >>> fold-const can't see through SSA statements. But this kind of >>> expansion should be reversed then by pass to the form (a | b) != 0 >>> back. >> >> ? fold-const shouldn't deal with this at all as we are in gimple and in >> SSA form. Surely re-association comes to play only with chains of >> the above with more than two operands. >> >> Richard. >> >>> >>> Regards, >>> Kai >>> >> > > The issue you can see by testcase binop_tor4.c, as here are the > intermediate variables d and e (with int type) are destroying the > reassociation pass. This testcase for example needs this sinking.
hoisting would work equally well > Kai >
