malloc cannot alias preexisting pointers
Marc Glisse
marc.glisse@inria.fr
Sun May 12 12:51:00 GMT 2019
On Sun, 12 May 2019, Richard Sandiford wrote:
> Marc Glisse <marc.glisse@inria.fr> writes:
>> Hello,
>>
>> this patch lets gcc know that if a pointer existed before the call to
>> malloc, the result of malloc cannot alias it. This is a bit ad hoc and
>> fragile. A small improvement would be, when the 2 statements are in the
>> same bb but in the wrong order, to check if there is any statement in
>> between that might prevent from reordering them. But that's more
>> complicated, and the patch as it is already does help.
>>
>> I expect people may not like the call to a function from
>> tree-ssa-loop-niter too much, but it is convenient. And if someone
>> improves it, they will likely have to rewrite something not quite
>> equivalent to stmt_dominates_stmt_p.
>
> It has linear complexity for statements in the same block though.
Ah, true. I should anyway test that the second statement is malloc
(cheaper) before checking for domination, but even then that could be used
to create a quadratic behavior :-(
> (reassoc_stmt_dominates_stmt_p avoids that, but relies on uids
> being up-to-date.)
This function is called from all over the place. Unless there is a simple
test to check if uids are safe to use (reassoc_in_progress?), that's going
to be a problem. I find it surprising that this information is so hard to
get to... Stopping stmt_dominates_stmt_p after walking 128 statements
doesn't feel like a great solution. But without controlling the pass where
this happens, I don't see any good solution. It would be great if that
non-aliasing property could be recorded in the points-to information, then
I could set it from a pass I control, but I somehow got the impression
that it wouldn't work. Maybe I should try to understand PTA better to make
sure.
--
Marc Glisse
More information about the Gcc-patches
mailing list