2012/1/25 Andrey Belevantsev <a...@ispras.ru>: > 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.
I'd prefer that. >> 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. Thanks, Richard. > Andrey
