On Wed, Mar 16, 2016 at 10:48 AM, Bin Cheng <bin.ch...@arm.com> wrote: > Hi, > When I tried to decrease # of IV candidates, I removed code that adds IV > candidates for use with constant offset stripped in use->base. This is kind > of too aggressive and triggers PR69042. So here is a patch adding back the > missing candidates. Honestly, this patch doesn't truly fix the issue, it > just brings back the original behavior in IVOPT part (Which is still a right > thing to do I think). The issue still depends on PIC_OFFSET register used on > x86 target. As discussed in > https://gcc.gnu.org/ml/gcc/2016-02/msg00040.html. Furthermore, the real > problem could be in register pressure modeling about PIC_OFFSET symbol in > IVOPT. > > On AArch64, overall spec2k number isn't changed, though 173.applu is > regressed by ~4% because couple of loops' # of candidates now hits "--param > iv-consider-all-candidates-bound=30". For spec2k6 data on AArch64, INT is > not affected; FP overall is not changed, as for specific case: 459.GemsFDTD > is regressed by 2%, 433.milc is improved by 2%. To address the regression, I > will send another patch increasing the parameter bound. > > Bootstrap&test on x86_64 and AArch64, is it OK? In the meantime, I will > collect spec2k6 data on x86_64.
Ok. Richard. > Thanks, > bin > > 2016-03-10 Bin Cheng <bin.ch...@arm.com> > > PR tree-optimization/69042 > * tree-ssa-loop-ivopts.c (add_iv_candidate_for_use): Add IV cand > for use with constant offset stripped in base.