On Wed, Oct 21, 2015 at 11:55 AM, Bin.Cheng <amker.ch...@gmail.com> wrote: > On Fri, Oct 9, 2015 at 8:04 PM, Bernd Schmidt <bschm...@redhat.com> wrote: >> On 10/09/2015 02:00 PM, Bin.Cheng wrote: >>> >>> I further bootstrap and test attached patch on aarch64. Also three >>> cases in spec2k6/fp are improved by 3~6%, two cases in spec2k6/fp are >>> regressed by ~2%. Overall score is improved by ~0.8% for spec2k6/fp >>> on aarch64 of my run. I may later analyze the regression. >>> >>> So is this patch OK? >> > Hi Bernd, > Thanks for reviewing this patch. I further collected perf data for > spec2k on AArch64. Three fp cases are improved by 3-5%, no obvious > regression. As for int cases, perlbmk is improved by 8%, but crafty > is regressed by 3.8%. Together with spec2k6 data, I think this patch > is generally good. I scanned hot functions in crafty but didn't find > obvious regression because lim hoist decision is very different > because of this change. The regression could be caused by register > pressure.. > >> >> I'll approve this with one change, but please keep an eye out for >> performance regressions on other targets. > Sure. > >> >>> * loop-invariant.c (struct def): New field cant_prop_to_addr_uses. >>> (inv_cant_prop_to_addr_use): New function. >> >> >> I would like these to have switched truthvalues, i.e. can_prop_to_addr_uses, >> inv_can_prop_to_addr_use. Otherwise we end up with double negations like >> !def->cant_prop_to_addr_uses which can be slightly confusing. >> >> You'll probably slightly need to tweak the initialization when n_addr_uses >> goes from zero to one. > Here is the new version patch with your comments incorporated. > Given the patch was pre-approved and there is no other comments, I will apply it later.
Thanks, bin
