> someone reported to me problems with his crosscompiler installation running
that's me.-)
> on Linux/Alpha. The problem is related to the type long being 64 bit on
> Alphas and results in GCC generating bad code which can most easily be
> recognices by huge (bigger than 2 << 32) constants in the code.
that's the obvious case, but the code is much worse. Here is a example:
mm/memory.c compiled on a 386:
.ent oom
oom:
.frame $sp,48,$31 # vars= 0, regs= 2/0, args= 32, extra= 0
.mask 0x80010000,-8
.fmask 0x00000000,0
lw $5,current_set
subu $sp,$sp,48
sd $16,32($sp)
move $16,$4
la $4,$LC2
sd $31,40($sp)
.set noreorder
.set nomacro
jal printk
addu $5,$5,498
.set macro
.set reorder
lw $2,940($16)
li $4,0x00000009 # 9
move $5,$16
sw $0,268($2)
lw $2,16($16)
li $3,-257 # 0xfffffeff
li $6,0x00000001 # 1
and $2,$2,$3
.set noreorder
.set nomacro
jal send_sig
sw $2,16($5)
.set macro
.set reorder
[....]
and now on the alpha:
oom:
.frame $sp,48,$31 # vars= 0, regs= 2/0, args= 32, extra= 0
.mask 0x80010000,-8
.fmask 0x00000000,0
lw $5,current_set
subu $sp,$sp,48
sd $16,32($sp)
move $16,$4
la $4,$LC2
sd $31,40($sp)
.set noreorder
.set nomacro
jal printk
addu $5,$5,498
.set macro
.set reorder
lw $2,940($16)
li $3,0x00000000ffff0000 # 4294901760
ori $3,$3,0xfeff
li $4,0x0000000000000009 # 9
sw $0,200($2)
lw $2,16($16)
move $5,$16
li $6,0x0000000000000001 # 1
and $2,$2,$3
.set noreorder
.set nomacro
jal send_sig
sw $2,16($5)
.set macro
.set reorder
[...]
I debugged gcc one day, and it looks like there are lot of conversion
HOST_WIDE_INT -> 32bit unsigned int -> 32bit signed int.
And because on the alpha HOST_WIDE_INT is 64bit wide, the strange
code above is generated.
Today I have done a quick hack, and compiled the cross compiler
with #define HOST_WIDE_INT int (which is 32bit wide). Now the
code looks much better, but there are still minor differences.
Any other hints, what I can do ?
Thomas.
--
That process _deserves_ to die ("My name is Linus Torvalds, prepare to
die"). [Linus Torvalds on linux-kernel]
|