https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 27 Nov 2014, jiwang at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 > > Jiong Wang <jiwang at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rguenth at gcc dot gnu.org > Depends on| |52563 > > --- Comment #12 from Jiong Wang <jiwang at gcc dot gnu.org> --- > the root cause why it's not ivopted on AArch64 is because > > must_check_src_overflow = TYPE_PRECISION (ct) < TYPE_PRECISION (type); > > code above in convert_affine_scev, the input type is sizetype, so DI for 64bit > arch, SI for 32bit arch, ct is SI, thus, must_check_src_overflow set to true > for 64bit arch, then failed later scev_probably_wraps_p check. > > And I found similar issue reported back in 2012, at bug 52563. > > I verified this bug exist on other 64 archs, like mips64, ppc64, x86-64 > > Richard, on 52563, I see you was working on this, do you have any thoughts on > this? See comment #5 of that bug. For 4.8(?) I started on work to relax the type requirements of the offset parameter of POINTER_PLUS_EXPR by abstracting stuff but I didn't get to continue on that work. Basically that we force the offset to 'sizetype' has both correctness issues (for targets where sizetype precision doesn't match Pmode precision) and optimization issues as we lose for example sign information and overflow knowledge in the computation of the offset. The last thing is also because we have transforms in fold which push typecasts of expressions down to operands - thus from (sizetype) (4 * i) we get 4 * (sizetype)i which may now be an unsigned multiplication with wrapping overflow. Note that it is the frontends who start the conversion thing and apply some "tricks" for code-gen (see pointer_int_sum in c-common.c). It's also not clear whether if you write p[i] with i of type int the multiplication by sizeof (*p) invokes undefined behavior if it wraps (that is, the C standard does not define the type the multiplication is performed in but just defines things in terms of array elements). Ideally we'd use a widening multiplication here but optimizers have little knowledge of that so it probably would cause quite some regressions. We could also keep the multiplication signed (but using ssizetype), but then fold will come along and undo that trick IIRC. That said, both the POINTER_PLUS_EXPR constraints on the offset type _and_ the C language issue with int * sizeof (element) overflowing for 64bit pointer sizes prevent us from optimizing this. It's a very tricky area ;)
