On Thu, May 27, 2021 at 5:38 AM bin.cheng via Gcc-patches
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) + 0xfffd: 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
