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
