From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15211 invoked by alias); 9 Jan 2003 09:06:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 15165 invoked by uid 71); 9 Jan 2003 09:06:01 -0000 Resent-Date: 9 Jan 2003 09:06:01 -0000 Resent-Message-ID: <20030109090601.15164.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, m-sasai@nms.nec.co.jp Resent-Reply-To: gcc-gnats@gcc.gnu.org, miles@gnu.org Received: (qmail 2370 invoked by uid 61); 9 Jan 2003 08:58:19 -0000 Message-Id: <20030109085819.2366.qmail@sources.redhat.com> Date: Thu, 09 Jan 2003 09:06:00 -0000 From: miles@gnu.org Reply-To: miles@gnu.org To: gcc-gnats@gcc.gnu.org Cc: m-sasai@nms.nec.co.jp X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) X-GNATS-Notify: m-sasai@nms.nec.co.jp Subject: optimization/9240: wierd scheduling on v850 unless -fno-sched-spec specified X-SW-Source: 2003-01/txt/msg00587.txt.bz2 List-Id: >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: