On Mon, Nov 19, 2018 at 9:17 PM Christophe Lyon
<christophe.l...@linaro.org> wrote:
>
> On Wed, 14 Nov 2018 at 11:10, bin.cheng <bin.ch...@linux.alibaba.com> wrote:
> >
> > ------------------------------------------------------------------
> > Sender:Richard Biener <richard.guent...@gmail.com>
> > Sent at:2018 Nov 13 (Tue) 23:03
> > To:bin.cheng <bin.ch...@linux.alibaba.com>
> > Cc:GCC Patches <gcc-patches@gcc.gnu.org>
> > Subject:Re: [PATCH PR84648]Adjust loop exit conditions for loop-until-wrap
> > cases.
> >
> > >
> > > On Sun, Nov 11, 2018 at 9:02 AM bin.cheng <bin.ch...@linux.alibaba.com>
> > > wrote:
> > >>
> > >> Hi,
> > >> This patch fixes PR84648 by adjusting exit conditions for
> > >> loop-until-wrap cases.
> > >> It only handles simple cases in which IV.base are constants because we
> > >> rely on
> > >> current niter analyzer which doesn't handle parameterized bound in
> > >> wrapped
> > >> case. It could be relaxed in the future.
> > >>
> > >> Bootstrap and test on x86_64 in progress.
> > >
> > > Please use TYPE_MIN/MAX_VALUE or wi::min/max_value consistently.
> > > Either tree_int_cst_equal (iv0->base, TYPE_MIN_VALUE (type)) or
> > > wide_int_to_tree (niter_type, wi::max_value (TYPE_PRECISION (type),
> > > TYPE_SIGN (type))).
> > >
> > > Also
> > >
> > > + iv0->base = low;
> > > + iv0->step = fold_convert (niter_type, integer_one_node);
> > >
> > > build_int_cst (niter_type, 1);
> > >
> > > + iv1->base = high;
> > > + iv1->step = integer_zero_node;
> > >
> > > build_int_cst (niter_type, 0);
> > Fixed, thanks for reviewing.
> >
> > >
> > > With the code, what happens to signed IVs? I suppose we figure out things
> > > earlier by means of undefined overflow?
> > The code takes advantage of signed undefined overflow and handle it as wrap.
> > In the reported test case, we have following IL:
> > <bb 2> :
> > goto <bb 4>; [INV]
> >
> > <bb 3> :
> > i_4 = i_2 + 1;
> >
> > <bb 4> :
> > # i_2 = PHI <0(2), i_4(3)>
> > i.0_1 = (signed int) i_2;
> > if (i.0_1 >= 0)
> > goto <bb 3>; [INV]
> > else
> > goto <bb 5>; [INV]
> >
> > So the IV is actually transformed into signed int, we rely on scev to
> > understand
> > type conversion correctly and generate (int){0, 1} for i.0_1. Is this
> > reasonable?
> >
> > Updated patch attached, bootstrap and test on x86_64.
> >
> > Thanks,
> > bin
> >
> > 2018-11-11 Bin Cheng <bin.ch...@linux.alibaba.com>
> >
> > PR tree-optimization/84648
> > * tree-ssa-loop-niter.c (adjust_cond_for_loop_until_wrap): New.
> > (number_of_iterations_cond): Adjust exit cond for loop-until-wrap
> > case
> > by calling adjust_cond_for_loop_until_wrap.
> >
> > 2018-11-11 Bin Cheng <bin.ch...@linux.alibaba.com>
> >
> > PR tree-optimization/84648
> > * gcc.dg/tree-ssa/pr84648.c: New test.
> > * gcc.dg/pr68317.c: Add warning check on overflow.
>
>
> Hi Bin,
>
> Since you committed this patch (r266171), I've noticed a regression
> in fortran:
Very sorry for the breakage. It's reported as pr88044, I will investigate it.
Thanks,
bin
> FAIL: gfortran.dg/transfer_intrinsic_3.f90 -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions execution
> test
> FAIL: gfortran.dg/transfer_intrinsic_3.f90 -O3 -g execution test
> on arm-none-linux-gnueabihf
> --with-cpu cortex-a5
> --with-fpu vfpv3-d16-fp16
>
> cortex-a9+neon-fp16, cortex-a15+neon-vfpv4 and
> cortex-a57+crypto-neon-fp-armv8 are still OK.
>
> Christophe
