From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-19669-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 24642 invoked by alias); 17 Jun 2002 23:46:10 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 24554 invoked by uid 71); 17 Jun 2002 23:46:02 -0000
Resent-Date: 17 Jun 2002 23:46:02 -0000
Resent-Message-ID: <20020617234602.24553.qmail@sources.redhat.com>
Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer)
Resent-To: nobody@gcc.gnu.org
Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Resent-Reply-To: gcc-gnats@gcc.gnu.org,
  Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
Received: (qmail 22149 invoked from network); 17 Jun 2002 23:37:53 -0000
Received: from unknown (HELO mailout03.sul.t-online.com) (194.25.134.81)
  by sources.redhat.com with SMTP; 17 Jun 2002 23:37:53 -0000
Received: from fwd07.sul.t-online.de 
	by mailout03.sul.t-online.com with smtp 
	id 17K64G-0003sy-04; Tue, 18 Jun 2002 01:37:52 +0200
Received: from localhost (520046482682-0001@[80.131.90.12]) by fmrl07.sul.t-online.com
	with esmtp id 17K64B-1GcKvoC; Tue, 18 Jun 2002 01:37:47 +0200
Received: from falk by localhost with local (Exim 3.35 #1 (Debian))
	id 17K63v-0001jw-00
	for <gcc-gnats@gcc.gnu.org>; Tue, 18 Jun 2002 01:37:31 +0200
Message-Id: <E17K63v-0001jw-00@localhost>
Date: Mon, 17 Jun 2002 20:36:00 -0000
From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
To: gcc-gnats@gcc.gnu.org
X-Send-Pr-Version: 3.113
Subject: optimization/7061: Alpha: Access of bytes in struct parameters
X-SW-Source: 2002-06/txt/msg00410.txt.bz2
List-Id: <gcc-prs.sourceware.org>


>Number:         7061
>Category:       optimization
>Synopsis:       Alpha: Access of bytes in struct parameters
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 17 16:46:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Falk Hueffner
>Release:        3.2 20020607 (experimental)
>Organization:
>Environment:
System: Linux borkum 2.4.18 #6 Wed Apr 24 22:18:43 CEST 2002 alpha unknown
Architecture: alpha

	
host: alphapca56-unknown-linux-gnu
build: alphapca56-unknown-linux-gnu
target: alphapca56-unknown-linux-gnu
configured with: ../configure --enable-languages=c
>Description:
struct s1 { unsigned char a, b; };
unsigned long f1(struct s1 x) {
    return x.a + x.b;
}
struct s2 { unsigned a: 8, b: 8; };
unsigned long f2(struct s2 x) {
    return x.a + x.b;
}

compiled with -O3 -mcpu=pca56 gives:

f1:	lda     sp,-16(sp)
	stw     a0,0(sp)
	ldbu    t1,0(sp)
	ldbu    t2,1(sp)
	addq    t1,t2,v0
	lda     sp,16(sp)
	ret

f2:	mov     a0,t0
	and     a0,0xff,t1
	extbl   t0,0x1,t2
	addq    t1,t2,v0
	ret

In the second case, gcc generates pretty much optimal code[1], whereas
in the first case, it spills the struct to the stack just to re-read
it in single bytes. While this doesn't look too terrible, it gets
really ugly with -mcpu=ev4 (which is default in most distributions),
which has no byte read/write opcodes.

It would be nice if for the first case similar code could be generated
as for the second case.

[1] Well, except for the spurious mov, and it could generate
    zap a0,0x03,v0; perr a0,v0,v0, but I don't expect it to :)
>How-To-Repeat:
	
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: