On Fri, Apr 22, 2016 at 4:26 PM, Christophe Lyon
<christophe.l...@linaro.org> wrote:
> On 21 April 2016 at 11:03, Richard Biener <richard.guent...@gmail.com> wrote:
>> On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng <bin.ch...@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.ch...@arm.com>
>>>
>>> PR tree-optimization/70715
>>> * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check equality
>>> after expanding BASE using expand_simple_operations.
