> Am 28.11.2023 um 18:38 schrieb Jan Hubicka <hubi...@ucw.cz>:
>
>
>>
>>
>>
>>>> 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?
Yeah, we currently don’t track (reliably) what parameters point to and whether
that escapes. Or rather, you can’t query this info.
Richard
> Honza
>>
>> Richard
>>
>>> Honza
>>>>
>>>> Richard.
