>
>
> > Am 28.11.2023 um 17:59 schrieb Jan Hubicka <hubi...@ucw.cz>:
> >
> >
> >>
> >>> On Tue, 28 Nov 2023, Martin Jambor wrote:
> >>>
> >>> On Tue, Nov 28 2023, Richard Biener wrote:
> >>>> On Mon, 27 Nov 2023, Martin Jambor wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> The enhancement to address PR 109849 contained an importsnt thinko,
> >>>>> and that any reference that is passed to a function and does not
> >>>>> escape, must also not happen to be aliased by the return value of the
> >>>>> function. This has quickly transpired as bugs PR 112711 and PR
> >>>>> 112721.
> >>>>>
> >>>>> Just as IPA-modref does a good enough job to allow us to rely on the
> >>>>> escaped set of variables, it sems to be doing well also on updating
> >>>>> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
> >>>>> exactly the situation we need to avoid. Of course, if a call
> >>>>> statement ignores any returned value, we also do not need to check the
> >>>>> flag.
> >>>>
> >>>> But what about EAF_NOT_RETURNED_INDIRECTLY? Don't you need to
> >>>> verify the parameter doesn't escape through the return at all?
> >>>>
> >>>
> >>> I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
> >>> param->next" but those are not a problem (whatever next points to cannot
> >>> be an SRA candidate and any ADDR_EXPR storing its address there would
> >>> trigger a disqualification or at least an assert). But I guess I am
> >>> wrong, what is actually the exact meaning of the flag?
> >>
> >> I thought it's return (x.ptr = param, &x);
> >>
> >> so the parameter is reachable from the return value.
> >>
> >> But let's Honza answer...
> > It is same difference as direct/indirect escape. so it check whether
> > values pointed to by arg can be possibly returned. Indeed maybe we
> > should think of better name - the other interpretation did not even
> > occur to me, but it makes sense.
>
> So does the directly returned flag cover my interpretation of indirect or is
> there a hole?
Stores goes through:
/* Handle *lhs = name. */
if (assign && gimple_assign_rhs1 (assign) == name)
{
if (dump_file)
fprintf (dump_file, "%*s ssa name saved to memory\n",
m_depth * 4, "");
m_lattice[index].merge (0);
}
So we give up on any flags. So far modref does not try to track values
in memory at all. I suppose PTA info does not help me here, since the
memory values is stored to may not escape but later it may be read and
copied into something that does escape?
Honza
>
> Richard
>
> > Honza
> >>
> >> Richard.
