On Fri, 23 Jul 2021, Jeff Law wrote: > > > On 7/15/2021 4:08 AM, Jiufu Guo via Gcc-patches wrote: > > Refine code for V2 according to review comments: > > * Use if check instead assert, and refine assert > > * Use better RE check for test case, e.g. (?n)/(?p) > > * Use better wording for target.def > > > > Currently, doloop.xx variable is using the type as niter which may be > > shorter than word size. For some targets, it would be better to use > > word size type. For example, on 64bit system, to access 32bit value, > > subreg maybe used. Then using 64bit type maybe better for niter if > > it can be present in both 32bit and 64bit. > > > > This patch add target hook for querg perferred mode for doloop IV. > > And update mode accordingly. > > > > Bootstrap and regtest pass on powerpc64le, is this ok for trunk? > > > > BR. > > Jiufu > > > > gcc/ChangeLog: > > > > 2021-07-15 Jiufu Guo <guoji...@linux.ibm.com> > > > > PR target/61837 > > * config/rs6000/rs6000.c (TARGET_PREFERRED_DOLOOP_MODE): New hook. > > (rs6000_preferred_doloop_mode): New hook. > > * doc/tm.texi: Regenerate. > > * doc/tm.texi.in: Add hook preferred_doloop_mode. > > * target.def (preferred_doloop_mode): New hook. > > * targhooks.c (default_preferred_doloop_mode): New hook. > > * targhooks.h (default_preferred_doloop_mode): New hook. > > * tree-ssa-loop-ivopts.c (compute_doloop_base_on_mode): New function. > > (add_iv_candidate_for_doloop): Call targetm.preferred_doloop_mode > > and compute_doloop_base_on_mode. > > > > gcc/testsuite/ChangeLog: > > > > 2021-07-15 Jiufu Guo <guoji...@linux.ibm.com> > > > > PR target/61837 > > * gcc.target/powerpc/pr61837.c: New test. > My first reaction was that whatever type corresponds to the target's word_mode > would be the right choice. But then I remembered things like dbCC on m68k > which had a more limited range. While I don't think m68k uses the doloop > bits, it's a clear example that the most desirable type may not correspond to > the word type for the target. > > So my concern with this patch is its introducing more target dependencies into > the gimple pipeline which is generally considered undesirable from a design > standpoint. Is there any way to lower from whatever type is chosen by ivopts > to the target's desired type at the gimple->rtl border rather than doing it in > ivopts?
I think that's difficult - after all we want to base other IV uses on the doloop IV if possible. So IMHO it's not different from IVOPTs choosing different IVs based on RTL costing and target addressing mode availability so I wasn't worried about those additional target dependences at this point of the GIMPLE pipeline. Richard.
