optimization/7061: Alpha: Access of bytes in struct parameters

[Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>]

>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: