This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFA][PR tree-optimization/79095] Improve overflow test optimization and avoid invalid warnings
On 01/26/2017 02:38 AM, Richard Biener wrote:
Marc mentions some reasons we have a lot of single_use predicates on condition
simplifications. You may want to evaluate some of the examples (usually
they boil down to RTL if-conversion missed optimizations). Other cases happen
when we can use CC flags of a previous computation that is live over the
conditional like
int foo (int b)
{
int a = b - 1;
if (a == 0)
return b;
return a;
}
if we transform that to if (b == 1) we lose because we don't see to undo that
on RTL (and we do seem to do that transform somewhere since basically
I'm pretty sure my pattern wouldn't make that transformation. However,
I would expect other existing patterns + forwprop to do that
transformation. It's easy enough to check. ANd yes, we're terrible at
re-using CC flags.
+ && wi::eq_p (@1, 1))
+ (out_eqneq_m1 @0 { wide_int_to_tree (TREE_TYPE (@0), wi::max_value
+ (TYPE_PRECISION (TREE_TYPE (@0)), UNSIGNED)); })
build_minus_one_cst (TREE_TYPE (@0))
+ (if (TYPE_UNSIGNED (TREE_TYPE (@0))
+ && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))
+ && wi::eq_p (@1, -1))
+ (out_eqneq_zero @0 { fold_convert (TREE_TYPE (@0), integer_zero_node) ;
})
build_zero_cst (TREE_TYPE (@0))
Yup. Should have used the existing build_XXX routines. Thanks.
+ (if (TYPE_UNSIGNED (TREE_TYPE (@0))
+ && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))
&& wi::ne_p (@1, 0)
&& single_use (@2))
(out @0 { wide_int_to_tree (TREE_TYPE (@0), wi::max_value
- (TYPE_PRECISION (TREE_TYPE (@0)), UNSIGNED) - @1); }))))
+ (TYPE_PRECISION (TREE_TYPE (@0)), UNSIGNED) - @1); }))))))
For a little CSE I'd use
(if (TYPE_UNSIGNED (TREE_TYPE (@0))
&& TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
(switch
(if (wi::eq_p (@1, 1))
...)
(if (wi::eq_p (@1, -1))
...)
(if (wi::ne_p (@1, 0) && single_use (@2))
...)))
which is also nicer for indentation.
Will fix if we go with the match.pd approach.
I also notice we dont' handle 1 - A CMP A anywhere.
Yea, I thought about that case, but decided against inclusion due to
stage4 and the lack of a testcase. It's enough enough to handle though
once we decide on the final form.
I've got a couple things to play with from Marc's message. Will post an
update on those findings ASAP.
jeff