This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH PR69042/01]Add IV candidate for use with constant offset stripped in base.


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.

Thanks,
bin

2016-03-10  Bin Cheng  <bin.cheng@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.

Attachment: pr69042-20160210.txt
Description: pr69042-20160210.txt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]