on 2019/5/15 上午11:34, Kewen.Lin wrote: > > on 2019/5/15 上午10:40, Bin.Cheng wrote: >> I wonder if you can factor out generic part into GIMPLE and leave >> target hook as specific as possible? >> > > Good suggestion! Yes, most of the checks are common as you > pointed out. I hope the other targets won't have more > customization needs excepting for that GIMPLE stmt hook > check. > > I am thinking IVOPTs is a best place to factor to? Or > somewhere to put common GIMPLE query interface? >
Or move it into targhooks.cpp as a possible base process of [target]_predict_doloop_p? The target owner can decide whether to use generic_predict_doloop_p in its own target hook. It seems more flexible and allow them to have a new implementation for their own targets. Like: rs6000_predict_doloop_p: .... if (generic_predict_doloop_p(loop)) ... special_target_predict_doloop_p: .... .... Thanks, Kewen >>> + >>> + /* Similar to doloop_optimize, check whether iteration count too small >>> + and not profitable. */ >>> + HOST_WIDE_INT est_niter = get_estimated_loop_iterations_int (loop); >>> + if (est_niter == -1) >>> + est_niter = get_likely_max_loop_iterations_int (loop); >>> + if (est_niter >= 0 && est_niter < 3) >> The only probably target dependent is the magic number 3 here. After >> moving all generic part to ivopts, we can use a macro for the moment, >> and improve it as a parameter if there are more doloop targets. > > The magic number 3 is from function doloop_optimize, not a > target dependent value. But thanks for your tips with > macro mechanism! > > > Thanks, > Kewen > >> Overall most of above checks can be moved out of backend, leaving only >> more specific target hook checking on gimple_stmt? And even that can >> be made generic to some extend. >> >> Thanks, >> bin >