[Flac-dev] Altivec Optimizations

[Brady Patterson]

Chris-

I upgraded to 10.2 and updated the developer tools, but am seeing the same
behavior. Can you help me with this?

gdb still always prints my VR contents as all 0, and the store vector
instruction still stores a suspicious-looking garbage value. I wrote a simple
program to demonstrate:

.text
	.align 2
.globl _vec_test
_vec_test:

; r3: buf

	vspltish v1,0
	stvewx v1,0,r3
	lwz r4,0(r3)
	vspltish v2,1
	stvewx v2,0,r3
	lwz r5,0(r3)

	blr

I'm assembling this using:

% as -static -g -force_cpusubtype_ALL -o test.o test.s

main() just verifies altivec existence using sysctl as described at
http://developer.apple.com/hardware/ve/g3_compatibility.html, then calls
vec_test() with a stack buffer.

Here is the relevant stuff from the debugger:

10	lwz r4,0(r3)
(gdb) p /x $r4
$9 = 0x7fffdead
(gdb) n
11	vspltish v2,1
(gdb) p $v2
$10 = {
  uint128 = 0x00000000000000000000000000000000,
  v4_float = {0, 0, 0, 0},
  v4_int32 = {0, 0, 0, 0},
  v8_int16 = {0, 0, 0, 0, 0, 0, 0, 0},
  v16_int8 = '\0' <repeats 15 times>
}
(gdb) n
12	stvewx v2,0,r3
(gdb) p /x $r5
$11 = 0xbffff948
(gdb) n
13	lwz r5,0(r3)
(gdb) p /x $r5
$12 = 0x7fffdead

To summarize, even after I splat 1 to v2, it still contains all 0s, and any
vector store writes 0x7fffdead, which apparently indicates the corresponding
VR is unused.

I've got OS X 10.2.5, gcc 3.1 20020420, and gdb 5.3-20021014 (Apple version
gdb-250) on a Powerbook G4.

Any idea what's going wrong?

Thanks.

-Brady

--
Brady Patterson (brady at spaceship.com)
Do you know Old Kentucky Shark?