optimization/7061: Alpha: Access of bytes in struct parameters
Falk Hueffner
falk.hueffner@student.uni-tuebingen.de
Tue Jun 18 04:30:00 GMT 2002
>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:
More information about the Gcc-bugs
mailing list