[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499

--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 18 May 2021, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
> 
> --- Comment #14 from bin cheng <amker at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #12)
> > So in number_of_iterations_ne it looks like the step 's' is always constant
> > which makes me wonder if we can somehow use ranger to tell multiple_of_p
> > (type, c, s)
> > or at least whether, if c is x * s, the multiplication could have overflowed?
> 
> Yeah, I am looking if "multiple of" can be feasibly checked in niter analysis,
> with help of some basic information from multiple_of_p.
> 
> BTW, I am not following changes in "ranger", how should I used in analysis? or
> similar to value range info?

I'm not sure - let's see if the ranger folks have any good idea here.

Btw, there's tree_ctz which looks more conservative and could be used
for power-of-two 's'.  split_constant_offset also recently got
refactoring to avoid a plethora of overflow issues it ran into,
so we can eventually improve multiple_of_p to be correct without
pre-conditions.  But I fear that for DECL_SIZE & friends where
we "know" that multiplications by 8 to get from byte to bit size
do not overflow we cannot be too conservative here.  Maybe in the
end we need to distinguish those with new MULT_NO_OVERFLOW,
PLUS_NO_OVERFLOW, etc.  When creating those expressions we should
already be using size_{bin,un}op.  The conversion handling of course
still looks bogus to me even in this context.