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