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

[amacleod at redhat dot com]

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

--- Comment #28 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to rguenther@suse.de from comment #27)
> On Wed, 26 May 2021, aldyh at redhat dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
> > 
> > --- Comment #26 from Aldy Hernandez <aldyh at redhat dot com> ---
> > On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de
> > <gcc-bugzilla@gcc.gnu.org> wrote:
> > 
> > > It's probably too strict for multiple_of_p which is fine with
> > > overflows that preserve modulo behavior.
> > 
> > Could you provide an example?
> 
> Like with DECL_SIZE being D.1234 * 8 as unsigned multiplication
> and the query whether it's a multiple of 8.  Once you have no
> range for 'D.1234' you will signal overflow (correctly) but
> even then it's still a mutliple of 8.

Determining whether an arbitrary expression is a multiple of some number is not
really something we can figure out via ranges. Well, that's not quite true. If
we fully fleshed out the operations you care about, things like multiply or
shift you could get some results. presumably things like multiply by 2,4,8 and
16.. if we created correct multi-ranges for those, a cast of the high precision
range back to the original precision would yield an identical non-varying
range. and for non-multiples/unsupported values we'd get varying or something
not the same as the original value?.  This would only work if the original
value doesn't come out varying.    Although if its varying, maybe you dont care
and a match is ok anyway?    We could have may_overflow_p also return the
higher precision range for inspection if its true...