On Tue, Jan 15, 2019 at 1:10 AM Andi Kleen <a...@linux.intel.com> wrote: > > On Mon, Jan 14, 2019 at 04:15:20PM +0800, Bin.Cheng wrote: > > On Mon, Jan 14, 2019 at 4:07 PM Andi Kleen <a...@linux.intel.com> wrote: > > > > > > Bin Cheng, > > > > > > I did some testing on this now. The attached patch automatically > > > increases the iterations > > > for autofdo profiles. > > Hi Andi, thanks very much for tuning these. > > > > > > But even with even more iterations I still have stable failures in > > > > > > FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler foo[._]+cold > > > FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler size[ > > > \ta-zA-Z0-0]+foo[._]+cold > > I think these two are supposed to fail with current code base. > > Sorry for being late. > We should mark it as XFAIL then I guess. Yeah > > Is it understood why it doesn't work? I didn't dig into it, but I think the reason is autofdo::zero count is not considered as cold as profile count. It's kind of reasonable, otherwise too much code would be categorized as cold. > > > > FAIL: gcc.dg/tree-prof/indir-call-prof.c scan-ipa-dump afdo "Indirect > > > call -> direct call.* a1 transformation on insn" > > I also got unstable pass/fail for indirect call optimization when > > tuning iterations, and haven't got an iteration number which passes > > all the time. I guess we need to combine decreasing of sampling count > > here. > > Okay I will look into that. > > Could also try if prime sample after values help, this sometimes fixes > problems with systematically missing some code in sampling. > > > > FAIL: gcc.dg/tree-prof/peel-1.c scan-tree-dump cunroll "Peeled loop ., 1 > > > times" > > This one should fail too. > > Same. Maybe I shouldn't use words "should fail", but the reason is we don't consider autofdo profile count as reliable in niters analysis. Maybe this can be improved somehow.
Thanks, bin > > -Andi
