This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for PR target/20632
- From: David Mosberger <davidm at napali dot hpl dot hp dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: James E Wilson <wilson at tuliptree dot org>,David Mosberger <davidm at hpl dot hp dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 1 Apr 2005 00:06:31 -0800
- Subject: Re: Patch for PR target/20632
- References: <200503251745.j2PHjhD6029735@napali.hpl.hp.com><424C3270.3060308@redhat.com><1112299953.3679.3.camel@aretha.corp.specifixinc.com><424C881E.3060508@redhat.com>
- Reply-to: davidm at hpl dot hp dot com
>>>>> On Thu, 31 Mar 2005 18:30:38 -0500, Vladimir Makarov <vmakarov@redhat.com> said:
Vlad> This is the final version patch has been committed into the
Vlad> mainline.
Cool. I tried it on the Linux kernel and we're down to 72 "nop.f 0"
instructions (from 71199!). The remaining nop.f's are
compiler-generated (not hand-coded) and they typically appear in
bundles like these:
0f f8 c8 22 13 20 [MMF] shladd r31=r50,4,r17
00 00 00 02 00 00 nop.m 0x0
00 00 04 00 nop.f 0x0;;
As far as I can see, the "nop.f" only occur in bundles where the
second slot contains a "nop.m 0".
More curiously, I found a handful of bundles containing only NOPs.
For example:
00 00 00 00 01 00 [MII] nop.m 0x0
a0 02 ae 3e 29 00 shr.u r42=r43,32
00 00 04 00 nop.i 0x0
0f 00 00 00 01 00 [MMF] nop.m 0x0
00 00 00 02 00 00 nop.m 0x0
00 00 04 00 nop.f 0x0;;
Is there a good reason to emit such a NOP-only bundle?
Thanks,
--david