[Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can

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

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 ;)