optimization/3756: gcc wishlist: arithmetic right shift for ternary operator

[Kevin Ryde <user42 at zip dot com dot au>]

>Number:         3756
>Category:       optimization
>Synopsis:       gcc wishlist: arithmetic right shift for ternary operator
>Confidential:   yes
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 20 18:26:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        3.0 (Debian) (Debian testing/unstable)
>Organization:
>Environment:
System: Linux blah 2.2.15 #1 Tue Apr 25 17:13:48 EST 2000 i586 unknown
Architecture: i586
	<machine, os, target, libraries (multiple lines)>
host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux

>Description:
It seems that, on i386 at least, gcc misses the opportunity to use an
arithmetic right shift when compiling a ternary expression like "n >=
0 ? a : b", for constant a and b.

>How-To-Repeat:
An example I first struck was

        int
        pn (int n)
        {
          return (n >= 0 ? 1 : -1);
        }

compiled with

        gcc-3.0 -O9 -fomit-frame-pointer -S pn.c

giving

	.file	"pn.c"
	.text
	.align 4
.globl pn
	.type	pn,@function
pn:
	movl	4(%esp), %eax
	notl	%eax
	shrl	$31, %eax
	leal	-1(%eax,%eax), %eax
	ret
.Lfe1:
	.size	pn,.Lfe1-pn
	.ident	"GCC: (GNU) 3.0 (Debian)"

I think instead of notl/shrl/leal it could do

        sarl    $31, %eax
        orl     $1, %eax

If I'm not mistaken "or" and "and" get used for that sort of thing
already, it's just the sarl that's missed.

A more general example

        int
        sel (int n)
        {
          return (n >= 0 ? 60 : 100);
        }

gives a slightly different form

        shrl    $31, %eax
        decl    %eax
        andl    $-40, %eax
        addl    $100, %eax

Again I think again the shrl+decl could be a sarl (and the constants
adjusted accordingly).
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: