This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why does -fschedule-insns2 in gcc 3.3 generates so many nops on ia64?
- From: "H. J. Lu" <hjl at lucon dot org>
- To: gcc at gcc dot gnu dot org
- Date: Sun, 20 Jul 2003 08:58:05 -0700
- Subject: Re: Why does -fschedule-insns2 in gcc 3.3 generates so many nops on ia64?
- References: <20030720144935.GA25711@lucon.org>
On Sun, Jul 20, 2003 at 07:49:35AM -0700, H. J. Lu wrote:
> While working on ia64 intrinsics, I noticed that gcc 3.3 added many
> nops around my new intrinsic when -fschedule-insns2 is used. I am
> enclosing 3 files here:
>
> 1. bar.i. The source code.
> 2. O.s. Assembly output generated by -O1.
> 3. schedule-insns2.s. Assembly output generated by -O1 -fschedule-insns2.
>
> As you can see, -fschedule-insns2 adds at least
>
> + .mii
> + nop.m 0
> + nop.i 0
> + ;;
> + nop.i 0
> + ;;
> + .mii
> + nop.m 0
> + nop.i 0
> + nop.i 0
> + ;;
> + .mii
> + nop.m 0
>
> What do I need to do to make gcc not to generate those nops and stop
> bits when -fschedule-insns2 is used?
>
schedule_ebbs () adds those nops and stop bits:
(insn 34 32 35 0 (nil) (unspec [
(const_int 0 [0x0])
] 23) 253 {bundle_selector} (nil)
(nil))
(insn 35 34 36 0 (nil) (const_int 1 [0x1]) 248 {nop_m} (nil)
(nil))
(insn 36 35 37 0 (nil) (const_int 2 [0x2]) 249 {nop_i} (nil)
(nil))
(insn 37 36 38 0 (nil) (unspec_volatile [
(const_int 2 [0x2])
] 2) -1 (nil)
(nil))
(insn 38 37 39 0 (nil) (const_int 2 [0x2]) 249 {nop_i} (nil)
(nil))
(insn 39 38 40 0 (nil) (unspec_volatile [
(const_int 3 [0x3])
] 2) -1 (nil)
(nil))
(insn 40 39 41 0 (nil) (unspec [
(const_int 0 [0x0])
] 23) 253 {bundle_selector} (nil)
(nil))
(insn 41 40 42 0 (nil) (const_int 1 [0x1]) 248 {nop_m} (nil)
(nil))
(insn 42 41 43 0 (nil) (const_int 2 [0x2]) 249 {nop_i} (nil)
(nil))
(insn 43 42 44 0 (nil) (const_int 2 [0x2]) 249 {nop_i} (nil)
(nil))
(insn 44 43 45 0 (nil) (unspec_volatile [
(const_int 3 [0x3])
] 2) -1 (nil)
(nil))
How can I make schedule_ebbs not to add those useless bundles and
stop bits?
H.J.