[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: [PATCH PR100499]Fix wrong niter info caused by overflow behavior
From:       Richard Biener via Gcc-patches <gcc-patches () gcc ! gnu ! org>
Date:       2021-05-31 10:01:55
Message-ID: CAFiYyc38Ld=M1LHvRnTAi4rTZczV8dAo0cR+aEb+9egYpLT7mQ () mail ! gmail ! com
[Download RAW message or body]

On Thu, May 27, 2021 at 5:38 AM bin.cheng via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Hi,
> As described in PR100499, loop niters analysis for "!=" now relies on multiple_of_p which
> so far is mostly implemented for no-overflow scenarios.  This patch fixes the issue by:
> 1. add new parameter to multiple_of_p indicating no-wrapping behavior in top expression.
> 2. pass new argument to help multiple_of_p, for example, the case in stor-layout.c.
> 3. adjust calls in number_of_iterations_ne by checking multiple_of_p without dependence
>     on wrapping/no-wrapping behavior.  It also corrects one issue in PR72817.
>
> Noticed there are some improvements in ranger to help analysis of multiple_of_p.  For
> TOP expression like "left op right", we would like to check if this specific op wraps or not.
> For example:
> 1. left (unsigned, multiple of 3) + 0xfffffffd: the result is multiple of 3 if "+" wraps even if
>     right operand is not multiple of 3.
> 2. left (unsigned, multiple of 3) + 6: the result is not multiple of 3 if "+" wraps even if the
>     right operand is multiple of 3.
> So in the end, we might need ranger to tell if such operator wraps or not, i.e, must_overflow,
> must_not_overflow, may_overflow.  Of course, we need to be conservative in the last case.
>
> Bootstrap and test on x86_64.  Any comments?

The multiple_of_p changes could have ABI impact on the 2nd occurance in
stor-layout.c, so a conservative fix would leave that one with
/*no_wrap = */true
as well.

In fact most of the scattered uses elsewhere should possibly converted to
wi::multiple_of_p.

Now,

+      if (!no_wrap && TYPE_OVERFLOW_WRAPS (type)
+         /* Overflow/wrap doesn't matter if the 2nd operand is power of 2. */
+         && !integer_pow2p (TREE_OPERAND (top, 1)))
+       return false;

are integer_pow2_p the only cases we can handle with ignoring overflow?
Isn't the other case when bottom is integer_pow2_p?
I wonder if it makes sense to wrap the core worker of multiple_of_p, using
tree_ctz for integer_pow2_p (bottom), that also already uses range/nonzero
bits info on SSA names.

That said - please factor out the niter analysis changes, they should be
valid on their own and it will be interesting to be able to bisect their
effect separately.

Thanks,
Richard.

> Thanks,
> bin
[prev in list] [next in list] [prev in thread] [next in thread]