On Thu, Nov 10, 2016 at 11:53:07PM +0100, Marc Glisse wrote:
> On Thu, 10 Nov 2016, Dominik Vogt wrote:
>
> >On Wed, Nov 09, 2016 at 03:46:38PM +0100, Richard Biener wrote:
> >>On Wed, Nov 9, 2016 at 3:30 PM, Dominik Vogt <v...@linux.vnet.ibm.com>
> >>wrote:
> >>>Something like the attached patch? Robin and me have spent quite
> >>>some time to figure out the new pattern. Two questions:
> >>>
> >>>1) In the match expression you cannot just use SSA_NAME@0 because
> >>> then the "case SSA_NAME:" is added to a switch for another
> >>> pattern that already has that label. Thus we made that "proxy"
> >>> predicate "ssa_name_p" that forces the code for the new pattern
> >>> out of the old switch and into a separate code block. We
> >>> couldn't figure out whether this joining of case labels is a
> >>> feature in the matching language. So, is this the right way to
> >>> deal with the conflicting labels?
> >>
> >>No, just do not match SSA_NAME. And instead of
> >>
> >>+ (with { gimple *def_stmt = SSA_NAME_DEF_STMT (@0); }
> >>+ (if (is_gimple_assign (def_stmt)
> >>+ && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
> >>
> >>you instead want to change the pattern to
> >>
> >>(simpify
> >> (cmp (convert @0) INTEGER_CST@1)
> >>
> >>@0 will then be your innerop
> >>
> >>note that you can't use get_value_range but you have to use the
> >>get_range_info interface instead. I suppose a helper function
> >>somewhere that computes whether an expression fits a type
> >>would be helpful (see expr_not_equal_to for sth related,
> >>thus expr_fits_type_p (@0, TREE_TYPE (@1)))
> >
> >All right, I think we got that (new patch attached).
> >
> >>Likewise the overflow_infinity checks do not translate to match.pd
> >>(or rahter the range info you get).
> >
> >Can you give us another hint here, please? The overflow check
> >should probably go into expr_fits_type_p, but with only the min
> >and max values from get_range_info, how can the overflow
> >TREE_OVERFLOW_P flag be retrieved from @1, to duplicate the logic
> >from is_{nega,posi}tive_overflow_infinity? Is it availably
> >somewhere, or is it necessary to somehow re-calculate it from the
> >expression?
> >
> >(This is really necessary so that cases like this don't start
> >folding with the patch:
> >
> >--
> >signed char foo3uu (unsigned char a)
> >{
> > unsigned char d;
> > unsigned long un;
> >
> > d = (a & 63) + 200;
> > un = d;
> > if (un >= 12)
> > ubar(un);
> >
> > return d;
> >}
> >--
>
> What's wrong with folding un >= 12 to d >= 12 (ignoring
> profitability, which you already handle with single_use)? I am not
> convinced we need the overflow stuff at all here.
This is the patch that added the overflow check:
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00037.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
--
PR tree-optimization/57124
* tree-vrp.c (simplify_cond_using_ranges): Only simplify a
conversion feeding a condition if the range has an
overflow
if -fstrict-overflow. Add warnings for when we do make
the
transformation.
PR tree-optimization/57124
* gcc.c-torture/execute/pr57124.c: New test.
* gcc.c-torture/execute/pr57124.x: Set
* -fno-strict-overflow.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@199305
138bc75d-0d04-0410-961f-82ee72b054a4
--
> +(for cmp (eq ne gt ge lt le)
>
> (for cmp (simple_comparison)
>
> + (cmp (convert@0 @1) INTEGER_CST@2)
> + (if (TREE_CODE (@1) == SSA_NAME
>
> (cmp (convert@0 SSA_NAME@1) INTEGER_CST@2)
>
> + (cmp { @1; } (convert @2))))))
>
> (cmp @1 (convert @2))))))
With some more cleaning:
(for cmp (simple_comparison)
(simplify
(cmp (convert@0 SSA_NAME@1) INTEGER_CST@2)
(if (!POINTER_TYPE_P (TREE_TYPE (@1))
&& !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (@1)
&& desired_pro_or_demotion_p (TREE_TYPE (@1), TREE_TYPE (@0)))
&& expr_fits_type_p (@1, TREE_TYPE (@0))
&& int_fits_type_p (@2, TREE_TYPE (@1))
&& (!has_single_use (@1) || has_single_use (@0)))
(cmp @1 (convert @2))))))
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
