On Wed, Jul 20, 2011 at 3:31 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > 2011/7/20 Richard Guenther <richard.guent...@gmail.com>: >> On Wed, Jul 20, 2011 at 3:05 PM, Kai Tietz <ktiet...@googlemail.com> wrote: >>> Hello, >>> >>> this is the revised version of the partial pre-approved patch for preserving >>> type-casts from/to boolean-types. It fixes additionally the regression in >>> tree-ssa/builtin-expect-5.c testcase, which was caused by >>> fold_builtin_expect. >>> Additionally there was a regression in gcc.dg/pr28685-1.c, which is fixed by >>> the change in tree-ssa-forwprop.c's function simplify_bitwise_binary. This >>> is just temporary necessary. As soon as we are boolifying comparisons in >>> gimplifier, the pattern-matching in tree-ssa-reassoc will match for 2 >>> branched cases >>> again and we can remove the hunk from forward-propagation again. >> >> Hm, if we can't apply this pieces without regressions we shouldn't. They >> can then wait for the boolification patch. >> >> Can you explain the fold_builtin_expect change? I'm lost in the maze >> of inner/inner_arg0/arg0 renaming game. It looks as if the patch only >> moves stuff - but that can't possibly be the case. So, what's going on >> there? > > Well, the issue is here that fold_builtin_expect checks here for a > comparison. If this comparison was created initially with a > boolean-type, the cast to 'long' will be in tree arg0 = (long) > CMP-with-boolean-type, as we are preserving here casts from > boolean-types (see the fold-const change). So we need to see through > this casts to match the compare and call cases. So I moved this "see > through" part before first pattern-match and introduced here a > helper-variable inner_arg0 to avoid double while-loop. The "inner" > variable might get invalid > ... > if (COMPARISON_CLASS_P (inner) > && TREE_CODE (TREE_OPERAND (inner, 1)) == INTEGER_CST) > inner = TREE_OPERAND (inner, 0); > ... > > These are those "prefixed casts" you were asking in the other patch about.
I see. So, if the builtin.c parts bootstrap & test ok then they are ok to commit separately. Thanks, Richard. > Regards, > Kai >
