This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c/3917: IA-64 assembler output shows erroneous cycle counting
- To: gbv at ctv dot es, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, wilson at gcc dot gnu dot org
- Subject: Re: c/3917: IA-64 assembler output shows erroneous cycle counting
- From: wilson at gcc dot gnu dot org
- Date: 20 Sep 2001 23:56:14 -0000
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