| Message ID | DB5PR08MB114462C918A8C3679BFA85BBE76D0@DB5PR08MB1144.eurprd08.prod.outlook.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng <Bin.Cheng@arm.com> wrote: > Hi, > As reported in PR70715, GCC failed to prove no-overflows of IV(&p[n]) for simple example like: > int > foo (char *p, unsigned n) > { > while(n--) > { > p[n]='A'; > } > return 0; > } > Actually, code has already been added to handle this form loops when fixing PR68529. Problem with this case is loop niter analyzer records control_IV with its base expanded by calling expand_simple_operations. This patch simply adds code expanding BASE before we check its equality against control_IV.base. In the long run, we might want to remove the use of expand_simple_operations. > > Bootstrap and test on x86_64. Is it OK? Ok. Richard. > Thanks, > bin > > > 2016-04-20 Bin Cheng <bin.cheng@arm.com> > > PR tree-optimization/70715 > * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality > after expanding BASE using expand_simple_operations.
On 21 April 2016 at 11:03, Richard Biener <richard.guenther@gmail.com> wrote: > On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng <Bin.Cheng@arm.com> wrote: >> Hi, >> As reported in PR70715, GCC failed to prove no-overflows of IV(&p[n]) for simple example like: >> int >> foo (char *p, unsigned n) >> { >> while(n--) >> { >> p[n]='A'; >> } >> return 0; >> } >> Actually, code has already been added to handle this form loops when fixing PR68529. Problem with this case is loop niter analyzer records control_IV with its base expanded by calling expand_simple_operations. This patch simply adds code expanding BASE before we check its equality against control_IV.base. In the long run, we might want to remove the use of expand_simple_operations. >> >> Bootstrap and test on x86_64. Is it OK? > Hi Bin, On ARM and AArch64 bare-metal toolchains, this causes FAIL: gcc.dg/tree-ssa/minmax-2.c scan-tree-dump optimized "__builtin_fmin" Christophe > Ok. > > Richard. > >> Thanks, >> bin >> >> >> 2016-04-20 Bin Cheng <bin.cheng@arm.com> >> >> PR tree-optimization/70715 >> * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality >> after expanding BASE using expand_simple_operations.
Hi Christophe, On 22/04/16 16:26, Christophe Lyon wrote: > On 21 April 2016 at 11:03, Richard Biener <richard.guenther@gmail.com> wrote: >> On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng <Bin.Cheng@arm.com> wrote: >>> Hi, >>> As reported in PR70715, GCC failed to prove no-overflows of IV(&p[n]) for simple example like: >>> int >>> foo (char *p, unsigned n) >>> { >>> while(n--) >>> { >>> p[n]='A'; >>> } >>> return 0; >>> } >>> Actually, code has already been added to handle this form loops when fixing PR68529. Problem with this case is loop niter analyzer records control_IV with its base expanded by calling expand_simple_operations. This patch simply adds code expanding BASE before we check its equality against control_IV.base. In the long run, we might want to remove the use of expand_simple_operations. >>> >>> Bootstrap and test on x86_64. Is it OK? > Hi Bin, > > On ARM and AArch64 bare-metal toolchains, this causes > > FAIL: gcc.dg/tree-ssa/minmax-2.c scan-tree-dump optimized "__builtin_fmin" Are you sure it's Bins' patch? I've seen that test fail on aarch64-none-elf since it was added recently. See https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01231.html Kyrill > Christophe > >> Ok. >> >> Richard. >> >>> Thanks, >>> bin >>> >>> >>> 2016-04-20 Bin Cheng <bin.cheng@arm.com> >>> >>> PR tree-optimization/70715 >>> * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality >>> after expanding BASE using expand_simple_operations.
On Fri, Apr 22, 2016 at 4:26 PM, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 21 April 2016 at 11:03, Richard Biener <richard.guenther@gmail.com> wrote: >> On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng <Bin.Cheng@arm.com> wrote: >>> Hi, >>> As reported in PR70715, GCC failed to prove no-overflows of IV(&p[n]) for simple example like: >>> int >>> foo (char *p, unsigned n) >>> { >>> while(n--) >>> { >>> p[n]='A'; >>> } >>> return 0; >>> } >>> Actually, code has already been added to handle this form loops when fixing PR68529. Problem with this case is loop niter analyzer records control_IV with its base expanded by calling expand_simple_operations. This patch simply adds code expanding BASE before we check its equality against control_IV.base. In the long run, we might want to remove the use of expand_simple_operations. >>> >>> Bootstrap and test on x86_64. Is it OK? >> > > Hi Bin, > > On ARM and AArch64 bare-metal toolchains, this causes > > FAIL: gcc.dg/tree-ssa/minmax-2.c scan-tree-dump optimized "__builtin_fmin" Hi Christophe, As Kyrill pointed out, it doesn't look likely. The case doesn't even have a loop for the patch to apply? Thanks, bin > > Christophe > >> Ok. >> >> Richard. >> >>> Thanks, >>> bin >>> >>> >>> 2016-04-20 Bin Cheng <bin.cheng@arm.com> >>> >>> PR tree-optimization/70715 >>> * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality >>> after expanding BASE using expand_simple_operations.
On 22 April 2016 at 17:38, Bin.Cheng <amker.cheng@gmail.com> wrote: > On Fri, Apr 22, 2016 at 4:26 PM, Christophe Lyon > <christophe.lyon@linaro.org> wrote: >> On 21 April 2016 at 11:03, Richard Biener <richard.guenther@gmail.com> wrote: >>> On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng <Bin.Cheng@arm.com> wrote: >>>> Hi, >>>> As reported in PR70715, GCC failed to prove no-overflows of IV(&p[n]) for simple example like: >>>> int >>>> foo (char *p, unsigned n) >>>> { >>>> while(n--) >>>> { >>>> p[n]='A'; >>>> } >>>> return 0; >>>> } >>>> Actually, code has already been added to handle this form loops when fixing PR68529. Problem with this case is loop niter analyzer records control_IV with its base expanded by calling expand_simple_operations. This patch simply adds code expanding BASE before we check its equality against control_IV.base. In the long run, we might want to remove the use of expand_simple_operations. >>>> >>>> Bootstrap and test on x86_64. Is it OK? >>> >> >> Hi Bin, >> >> On ARM and AArch64 bare-metal toolchains, this causes >> >> FAIL: gcc.dg/tree-ssa/minmax-2.c scan-tree-dump optimized "__builtin_fmin" > Hi Christophe, > As Kyrill pointed out, it doesn't look likely. The case doesn't even > have a loop for the patch to apply? > Ha, you are right, sorry for the noise. I've had a lot of infrastructure problems these days with many build failures, introducing noise in the results :( Christophe > Thanks, > bin >> >> Christophe >> >>> Ok. >>> >>> Richard. >>> >>>> Thanks, >>>> bin >>>> >>>> >>>> 2016-04-20 Bin Cheng <bin.cheng@arm.com> >>>> >>>> PR tree-optimization/70715 >>>> * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality >>>> after expanding BASE using expand_simple_operations.
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c index 81689fc..c61083e 100644 --- a/gcc/tree-ssa-loop-niter.c +++ b/gcc/tree-ssa-loop-niter.c @@ -4141,7 +4141,11 @@ loop_exits_before_overflow (tree base, tree step, continue; /* Done proving if this is a no-overflow control IV. */ - if (operand_equal_p (base, civ->base, 0)) + if (operand_equal_p (base, civ->base, 0) + /* Control IV is recorded after expanding simple operations, + Here we compare it against expanded base too. */ + || operand_equal_p (expand_simple_operations (base), + civ->base, 0)) return true; /* If this is a before stepping control IV, in other words, we have diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-11.c b/gcc/testsuite/gcc.dg/tree-ssa/scev-11.c new file mode 100644 index 0000000..b9223c8 --- /dev/null +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-11.c @@ -0,0 +1,15 @@ +/* { dg-do compile } */ +/* { dg-options "-O3 -fdump-tree-ldist" } */ + +int +foo (char *p, unsigned n) +{ + while(n--) + { + p[n]='A'; + } + return 0; +} + +/* Loop can be transformed into builtin memset since &p[n] is SCEV. */ +/* { dg-final { scan-tree-dump "builtin_memset" "ldist" } } */
Hi, As reported in PR70715, GCC failed to prove no-overflows of IV(&p[n]) for simple example like: int foo (char *p, unsigned n) { while(n--) { p[n]='A'; } return 0; } Actually, code has already been added to handle this form loops when fixing PR68529. Problem with this case is loop niter analyzer records control_IV with its base expanded by calling expand_simple_operations. This patch simply adds code expanding BASE before we check its equality against control_IV.base. In the long run, we might want to remove the use of expand_simple_operations. Bootstrap and test on x86_64. Is it OK? Thanks, bin 2016-04-20 Bin Cheng <bin.cheng@arm.com> PR tree-optimization/70715 * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality after expanding BASE using expand_simple_operations.