On 25.01.2012 16:38, Richard Guenther wrote:
2012/1/25 Andrey Belevantsev<a...@ispras.ru>:
Hello,
In this PR data dependence analysis goes wild by trying to process>20k
datarefs, so the patch limits the number of datarefs per loop we handle to
1000 via a param. On the way find_data_references_in_loop is made static
and predcom/parloops are fixed for compute_data_dependences_for_loop
returning false.
Bootstrapped and tested on x86_64-linux, no testcase as it is really a
memory hog. Strictly speaking, this could be a regression only from the
time when -O3 didn't have predcom/vectorization turned on by default, so --
ok for trunk or 4.8? Branches?
You limit the number of data references we find - but that isn't really
the scalability issue (it's linear in the number of stmts). It's really
compute_all_dependences that hits the quadraticness, thus _that_
function should fail instead (I realize it doesn't return any success/failure
state yet, but the number of callers is limited).
Sure, I've just had the impression that the datarefs vector is no use
without the dependencies themselves. The possibility of making
find_data_references_in_loop static also kind of hints in this direction.
Anyways, I don't have any problem with fixing compute_all_dependences instead.
Btw, new params need documentation in doc/invoke.texi.
Bah, I convinced myself params.def was the only documentation :-)
The tree-predcom.c and tree-parloops.c changes are ok for trunk anyway.
I will commit them separately.
Andrey
