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.

Reply via email to