https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #15 from Jan Hubicka <hubicka at ucw dot cz> ---
>
> IVOPTs does the above but it does it (or should) as
>
> offset = (uintptr)&base2 - (uintptr)&base1;
> val = *((T *)((uintptr)base1 + i + offset))
>
> which is OK for points-to as no POINTER_PLUS_EXPR is involved so the
> resulting pointer points to both base1 and base2 (which isn't optimal
> but correct).
>
> If we somehow get back a POINTER_PLUS that's where things go wrong.
>
> Doing the above in C code would be valid input so we have to treat
> it correctly (OK, the standard only allows back-and-forth
> pointer-to-integer casts w/o any adjustment, but of course we relax
> this).
OK. Modrefs tracks base pointer for accesses and tries to prove that
they are function parameters. This should immitate ivopts:
void
__attribute__ ((noinline))
set(int *a, unsigned long off)
{
*(int *)((unsigned long)a + off) = 1;
}
int
test ()
{
int a;
int b = 0;
set (&a, (unsigned long)&b - (unsigned long)&a);
return b;
}
Here set gets following gimple at modref2 time:
__attribute__((noinline))
void set (int * a, long unsigned int off)
{
long unsigned int a.0_1;
long unsigned int _2;
int * _3;
<bb 2> [local count: 1073741824]:
a.0_1 = (long unsigned int) a_4(D);
_2 = a.0_1 + off_5(D);
_3 = (int *) _2;
*_3 = 1;
return;
}
This is not pattern matched so modref does not think the access has a as
a base:
stores:
Base 0: alias set 1
Ref 0: alias set 1
Every access
While for:
void
__attribute__ ((noinline))
set(int *a, unsigned long off)
{
*(a+off/sizeof(int))=1;
}
we produce:
__attribute__((noinline))
void set (int * a, long unsigned int off)
{
sizetype _1;
int * _2;
<bb 2> [local count: 1073741824]:
_1 = off_3(D) & 18446744073709551612;
_2 = a_4(D) + _1;
*_2 = 1;
return;
}
And this is understood:
stores:
Base 0: alias set 1
Ref 0: alias set 1
access: Parm 0
If we consider it correct to optimize out the conversion from and to
pointer type, then I suppose any addition of pointer and integer which
we do not see means that we need to give up on tracking base completely.
I guess PTA gets around by tracking points-to set also for non-pointer
types and consequently it also gives up on any such addition.
But what we really get from relaxing this?
>
> IVOPTs then in putting all of the stuff into 'offset' gets at
> trying a TARGET_MEM_REF based on a NULL base but that's invalid.
> We then resort to a LEA (ADDR_EXPR of TARGET_MEM_REF) to compute
> the address which gets us into some phishy argument that it's
> not valid to decompose ADDR_EXPR of TARGET_MEM_REF to
> POINTER_PLUS of the TARGET_MEM_REF base and the offset. But
> that's how it is (points-to treats (address of) TARGET_MEM_REF
> as pointing to anything ...).
>
> > A quick fix would be to run IPA modref before ivopts, but I do not see how
> > such
> > transformation can work with rest of alias analysis (PTA etc)
>
> It does. Somewhere IPA modref interprets things wrongly, I didn't figure
> out here though.
I guess PTA gets around by tracking points-to set also for non-pointer
types and consequently it also gives up on any such addition.
I think it is ipa-prop.c::unadjusted_ptr_and_unit_offset. It accepts
pointer_plus expression, but does not look through POINTER_PLUS.
We can restrict it further, but tracking base pointer is quite useful,
so it would be nice to not give up completely.
Honza
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
