https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #13)
> (In reply to Tamar Christina from comment #12)
> > Looks like the problem is that during ao_ref_init_from_ptr_and_range when
> > initializing vectp_target.14_54 = &targetD.4595 + _55;
> >
> > we don't enter the block splitting apart POINTER_PLUS_EXPR.
> >
> > So it ends up creating a ref with the base being MEM_REF <&targetD.4595 +
> > _55>
> >
> > later on when checking of &targetD.4595 and MEM_REF <&targetD.4595 + _55>
> > could alias in refs_may_alias_p it doesn't think these two can alias, even
> > though
> >
> > # _38 = PHI <niters_vector_mult_vf.6_33(6), 0(3)>
> > # RANGE [irange] sizetype [0, 0][32, 4294967264] MASK 0xffffffe0 VALUE 0x0
> > _55 = (sizetype) _38;
> >
> >
> > so clearly they can alias. Need to look into how tree-ssa-alias normally
> > handles PHI offsets.
>
> The problem is that _55 is negative. But the alias oracle does not consider
> negative offsets but only the 8B positive offset which makes the access
> clearly out of bounds of &targetD.4595.
>
> Do not use POINTER_PLUS_EXPR to "advance" a pointer to sth outside of
> [&object, &object + sizeof(object)], since such a pointer is UB.
In fact it might not even help to perform this addition in uintptr_t since
points-to analysis is smart enough to see through those. And if you
cast that back to a pointer that pointer still cannot alias &target.
That means we currently do not have any means to do a .MASK_{LOAD,STORE}
that's correct to perform the alignment peeling with mask. And there's
no standards compliant way to do this using intrinsics either (you have
to form the pointer for this as well).
IVOPTs has a similar issue with computing &a - &b and offsetting that, but
in the end the pointer values computed in uintptr_t always point to where
the original program pointed to, so there uintptr_t computation + casting
back to a pointer works. But this is different - we are creating an
access that, from an alias perspective, starts before the object.
I guess a temporary way out would be to hide the constant negative offset, the
one that creeps in into
.MASK_STORE (vectp_target.14_54, 8B, max_mask_63, { 0, ... });
I'm not sure this will avoid points-to smarts, but at least the offset
tracking it does isn't reflected into the points-to sets. And we are
not re-running points-to analysis after vectorization (we just have that
pointer def following smarts).
