public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: wilson@gcc.gnu.org To: gbv@ctv.es, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, wilson@gcc.gnu.org Subject: Re: c/3917: IA-64 assembler output shows erroneous cycle counting Date: Thu, 20 Sep 2001 16:56:00 -0000 [thread overview] Message-ID: <20010920235614.2125.qmail@sourceware.cygnus.com> (raw) Synopsis: IA-64 assembler output shows erroneous cycle counting State-Changed-From-To: analyzed->closed State-Changed-By: wilson State-Changed-When: Thu Sep 20 16:56:14 2001 State-Changed-Why: I looked at the issue of making better choices about putting padding nops into partially full bundles. The info we need to make a better choice is not easily available at the place where we need to make the choice. I tried adding a quick hack to pad with a nop if a bundle has the first two slots full, and the split point was after the third slot. I would expect this to show some performancce improvement, but not as much as we could do if we had better info available. Index: ia64.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/ia64/ia64.c,v retrieving revision 1.120 diff -p -r1.120 ia64.c *** ia64.c 2001/08/23 19:27:54 1.120 --- ia64.c 2001/09/19 18:44:24 *************** cycle_end_fill_slots (dump) *** 5508,5513 **** --- 5523,5537 ---- slot++; } #endif + + if ((slot == 2 && sched_data.split >= 3) + || (slot == 5 && sched_data.split == 6)) + { + sched_data.types[slot] = packet->t[slot]; + sched_data.insns[slot] = 0; + sched_data.stopbit[slot] = 0; + slot++; + } sched_data.first_slot = sched_data.cur = slot; } I tried running spec95 int and fp benchmarks, with no patch, the first patch, and both patches. I also added a hack to disable Jan Hubicka's July 15 loop.c patch, which is causing performance regressions. I get no observable performancec increase from the first patch, and I get a small performance decrease from the second patch. From this I conclure that my first patch is desirable, but my second one is not, and that no further investigation is worthwhile at the moment for this problem. We will still have the problem that the scheduler will occasionally put two FP insns in different cycles when they could go in the same cycle, but in most cases the scheduler should now get this right, and I see no performance increase from trying to fix the remaining cases. I will be checking in my first patch. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3917&database=gcc
next reply other threads:[~2001-09-20 16:56 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-09-20 16:56 wilson [this message] -- strict thread matches above, loose matches on Subject: below -- 2001-09-17 22:24 wilson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20010920235614.2125.qmail@sourceware.cygnus.com \ --to=wilson@gcc.gnu.org \ --cc=gbv@ctv.es \ --cc=gcc-bugs@gcc.gnu.org \ --cc=gcc-prs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).