On Fri, Jun 21, 2024 at 3:02 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > This patch adds > > --param=vrp-block-limit=N > > When the basic block counter for a function exceeded 'N' , VRP is > invoked with the new fast_vrp algorithm instead. This algorithm uses a > lot less memory and processing power, although it does get a few less > things. > > Primary motivation is cases like > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 in which the 3 VRP > passes consume about 600 seconds of the compile time, and a lot of > memory. With fast_vrp, it spends less than 10 seconds total in the > 3 passes of VRP. This test case has about 400,000 basic blocks. > > The default for N in this patch is 150,000, arbitrarily chosen. > > This bootstraps, (and I bootstrapped it with --param=vrp-block-limit=0 > as well) on x86_64-pc-linux-gnu, with no regressions. > > What do you think, OK for trunk?
+ if (last_basic_block_for_fn (fun) > param_vrp_block_limit || + &data == &pass_data_fast_vrp) || goes to the next line. Btw, we have -Wdisabled-optimization for these cases which should say sth like "function has excess of %d number of basic blocks (--param vrp-block-limit=%d), using fast VRP algorithm" or so in this case. As I wrote in the PR the priority should be -O1 compile-time performance and memory use. Richard. > Andrew > > PS sorry,. it doesn't help the threader in that PR :-( It's probably one of the known bottlenecks there - IIRC the path range queries make O(n^2) work. I can look at this at some point as I've dealt with the slowness of this pass in the past. There is param_max_jump_thread_paths that should limit searching but there is IIRC no way to limit the work path ranger actually does when resolving the query. Richard.
