public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: miles@gnu.org To: gcc-gnats@gcc.gnu.org Cc: m-sasai@nms.nec.co.jp Subject: optimization/9240: wierd scheduling on v850 unless -fno-sched-spec specified Date: Thu, 09 Jan 2003 09:06:00 -0000 [thread overview] Message-ID: <20030109085819.2366.qmail@sources.redhat.com> (raw) >Number: 9240 >Category: optimization >Synopsis: wierd scheduling on v850 unless -fno-sched-spec specified >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: pessimizes-code >Submitter-Id: net >Arrival-Date: Thu Jan 09 01:06:00 PST 2003 >Closed-Date: >Last-Modified: >Originator: Miles Bader >Release: gcc (GCC) 3.4 20030108 (experimental) >Organization: >Environment: gcc compiled on debian unstable i686 cross-compiling for v850e-elf configure args are: configure --prefix=... --target=v850e-elf --host=i386-pc-linux-gnu --with-newlib --enable-languages=c --configure-cache=../config.cache >Description: When given the source file below (`gcc-3.x-sched-bug.c'), gcc cross-compiling for the v850 generates very oddly scheduled assembly. Old versions of gcc (e.g., 2.9x) or using the `-fno-sched-spec' option both cause much better code to be generated. Here's the (slightly edited) assembly output generated from `v850e-elf-gcc -S -O5 gcc-3.x-sched-bug.c': _bogus: /* compute r10 */ mov r10,r12 subr r0,r12 movea lo(-125),r0,r5 cmp r5,r10 bge .L3 .L2: jmp [r31] .L3: mov hilo(_errno),r5 st.w r12,0[r5] mov -1,r10 br .L2 Note that: (1) It's moved much of the calculation for the error case before the test, which I can see no reason for (especially since the v850 is such a simple processor -- no confusing speculative scheduling here!), and which pessimizes the normal path. (2) Even if there were a good reason for such scheduling for the error branch, use of __builtin_expect as shown arguably should have suppressed it, since it adversely effects the normal path. Here's the output when using the -fno-sched-spec option (other args the same), which is much, much, better: _bogus: /* compute r10 */ movea lo(-125),r0,r5 cmp r5,r10 bge .L3 .L2: jmp [r31] .L3: subr r0,r10 mov hilo(_errno),r5 st.w r10,0[r5] mov -1,r10 br .L2 >How-To-Repeat: Here's the source (`gcc-3.x-sched-bug.c'): extern int errno; int bogus () { register int val asm ("r10"); asm volatile ("/* compute r10 */" : "=r" (val)); if (__builtin_expect (val >= -125, 0)) { errno = -val; val = -1; } return val; } Compile it with: v850e-elf-gcc -S -O5 gcc-3.x-sched-bug.c >Fix: This particular problem can be avoided by using the -fno-sched-spec option; however I do no know if doing so adversely affects other code. >Release-Note: >Audit-Trail: >Unformatted:
reply other threads:[~2003-01-09 9:06 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20030109085819.2366.qmail@sources.redhat.com \ --to=miles@gnu.org \ --cc=gcc-gnats@gcc.gnu.org \ --cc=m-sasai@nms.nec.co.jp \ /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).