https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125285
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
PTA computes
# PT = null
SR.5_10 = MEM[(const struct cmf3D.2995 *)&predD.3382].f_D.2997.__pfnD.2991;
but none of the involved vars escapes. For
MEM <boolD.2947 PredD.2981::<T427> (const struct PredD.2981 *, charD.10) *>
[(struct *)&D.3301] = checkD.2985;
we get
D.3301.0+64 = &_ZNK4Pred5checkEc
D.3301.64+64 = &_ZNK4Pred5checkEc
that seems to be a missed optimization in PTA. The 'null' shouldn't happen,
we set vars_contains_nonlocal but possibly without any other var set this
might not be printed:
SR.5_10, points-to NULL, points-to vars: { } (nonlocal)
PTA doesn't track FUNCTION_DECLs or LABEL_DECLs:
/* Nothing should read/write from/to code so we can
save bits by not including them in the points-to bitmaps.
Still mark the points-to set as containing global memory
to make code-patching possible - see PR70128. */
That we set both fields is because of
/* The start of the access might happen anywhere
within vi, so conservatively assume it was
at its end. */
if (curr->offset - (vi->offset + vi->size - 1) < size)
{
we're missing optimizing the exact field match case here by doing
the pointer-offset -> deref generalization.
We fail in FRE when trying to handle
# .MEM_6 = VDEF <.MEM_8>
b.f_ = VIEW_CONVERT_EXPR<struct cmf3>(D.3301);
/* i now points to the first additional op.
??? LHS may not be completely contained in VR, one or more
VIEW_CONVERT_EXPRs could be in its way. We could at least
try handling outermost VIEW_CONVERT_EXPRs. */
if (j != -1)
return (void *)-1;
when matching up the access
{mem_ref<(A64)(struct bind_t *)0B>,addr_expr<&b>}
with the LHS
{component_ref<f_>,mem_ref<(A64)(struct bind_t *)0B>,addr_expr<&b>}
that is, the b.f_ assignment doesn't fully cover 'b'. It does cover
relevant parts but this isn't something we handle. The mistake
is that we end up with the access with dropped .f_.__pfn component,
but that got lost when handling pred = b. It seems to work for
the following though, so it's not exactly that.
struct S { int y; };
struct R { struct S s; int z; };
int foo (int x)
{
struct S s;
struct R r1, r2;
s.y = x;
r1.s = s;
r2 = r1;
return r2.s.y;
}
a smaller C/C++ testcase would be nice to have. I doubt this is a regression
in FRE.
