On Sun, 12 May 2019, Richard Sandiford wrote:
Marc Glisse <marc.gli...@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
