Re: [PATCH PR70715]Expand simple operations in IV.base and check if it's the control_IV

[Christophe Lyon]

On 22 April 2016 at 17:38, Bin.Cheng  wrote:
> On Fri, Apr 22, 2016 at 4:26 PM, Christophe Lyon
>  wrote:
>> On 21 April 2016 at 11:03, Richard Biener  wrote:
>>> On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng  wrote:
 Hi,
 As reported in PR70715, GCC failed to prove no-overflows of IV([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  

 PR tree-optimization/70715
 * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check 
 equality
 after expanding BASE using expand_simple_operations.

Re: [PATCH PR70715]Expand simple operations in IV.base and check if it's the control_IV

[Bin.Cheng]

On Fri, Apr 22, 2016 at 4:26 PM, Christophe Lyon
 wrote:
> On 21 April 2016 at 11:03, Richard Biener  wrote:
>> On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng  wrote:
>>> Hi,
>>> As reported in PR70715, GCC failed to prove no-overflows of IV([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  
>>>
>>> PR tree-optimization/70715
>>> * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality
>>> after expanding BASE using expand_simple_operations.

Re: [PATCH PR70715]Expand simple operations in IV.base and check if it's the control_IV

[Kyrill Tkachov]

Hi Christophe,

On 22/04/16 16:26, Christophe Lyon wrote:

On 21 April 2016 at 11:03, Richard Biener  wrote:

On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng  wrote:

Hi,
As reported in PR70715, GCC failed to prove no-overflows of IV([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  

 PR tree-optimization/70715
 * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality
 after expanding BASE using expand_simple_operations.

Re: [PATCH PR70715]Expand simple operations in IV.base and check if it's the control_IV

[Christophe Lyon]

On 21 April 2016 at 11:03, Richard Biener  wrote:
> On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng  wrote:
>> Hi,
>> As reported in PR70715, GCC failed to prove no-overflows of IV([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  
>>
>> PR tree-optimization/70715
>> * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality
>> after expanding BASE using expand_simple_operations.

Re: [PATCH PR70715]Expand simple operations in IV.base and check if it's the control_IV

[Richard Biener]

On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng  wrote:
> Hi,
> As reported in PR70715, GCC failed to prove no-overflows of IV([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  
>
> PR tree-optimization/70715
> * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality
> after expanding BASE using expand_simple_operations.

[PATCH PR70715]Expand simple operations in IV.base and check if it's the control_IV

[Bin Cheng]

Hi,
As reported in PR70715, GCC failed to prove no-overflows of IV([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  

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 000..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 [n] is SCEV.  */
+/* { dg-final { scan-tree-dump "builtin_memset" "ldist" } } */