---- Reported by grompf@sublimeintervention.com 2004-11-21 20:52:07 MST ----

The attached testcase below is a subset of vararg.il.  The basic block output is:

(for the important part)

<snip>
converting (in B8: stack: 0) IL_002c: ldloc.s   1
converting (in B8: stack: 1) IL_002e: refanytype
converting (in B8: stack: 1) IL_0030: call      0x0a000001
converting (in B8: stack: 1) IL_0035: ldtoken   0x1b000001
converting (in B8: stack: 2) IL_003f: ceq       
converting (in B8: stack: 1) IL_0041: brfalse   IL_004c
<snip>

DUMP BLOCK 8:
 (outarg_vt (refanytype (ldobj regoffset[0x34(ppc_r31)])))
 (stind.ref regoffset[0x54(ppc_r31)] call[GetTypeFromHandle])
 (beq[B9B10] (compare (ceq (compare (ldind.ref regoffset[0x54(ppc_r31)]) iconst[4570800])) 
iconst[0]))

<snip>
LOCAL regalloc: basic block: 8
        1  move R33 <- ppc_r31
        2  add_imm R33 <- R33
        3  load_membase R32 <- R33
        4  setreg ppc_r3 <- ppc_r0 clobbers: r
        5  call R34 <- clobbers: c
        6  store_membase_reg ppc_r31 <- R34
        7  load_membase R36 <- ppc_r31
        8  compare_imm R36
        9  ceq R35 <-
        10 compare_imm R35
        11 beq

like 4 doing the setreg of ppc_r0 -> r3 is improper before the call; the call should pass the R32 
value in ppc_r3.

The asm for this block is
000000f0        or      r3,r31,r31
000000f4        addi    r3,r3,0x34
000000f8        lwz     r3,0x0(r3)
000000fc        or      r3,r0,r0
00000100        bl      0x1d8
00000104        stw     r3,0x54(r31)
00000108        lis     r11,0x45
0000010c        ori     r11,r11,0xbeb0
00000110        cmpw    r3,r11
00000114        li      r3,0x0
00000118        bne     0x120
0000011c        li      r3,0x1
00000120        cmpwi   r3,0x0
00000124        beq     0x140

as you can see it does a mr r3,r0

Should this not be (in this case) skipped?

Am I missing something obvious?

(I tested 1.0.4 as well so this isn't a (recent) regression afaik)

-kangaroo



---- Additional Comments From grompf@sublimeintervention.com 2004-11-23 01:01:14 MST ----

I dug into this issue a little more and the instructions are being chained properly but for 
some reason when it gets to
stmt: OP_OUTARG_VT (reg)
state->left->tree->dreg is 0; even tho its been set to 3 in the OP_REFANYTYPE 
instruction.

The attached patch below fixes this problem by chaining them manually in inssel-ppc.brg

It should be noted that s390 has the same behaviour and it appears sparc does as well 
(they already override the chain in the burg file)

-kangaroo



---- Additional Comments From grompf@sublimeintervention.com 2004-11-23 01:01:48 MST ----

Created an attachment (id=167073)
patch




---- Additional Comments From lupus@ximian.com 2004-12-07 05:02:43 MST ----

reg in the rule is represented as state->left->reg1, not
state->left->tree->dreg. The bug was in the x86 code as well, just
not triggered.
Thanks for tracking down the issue.

Imported an attachment (id=167073)

Unknown operating system unknown. Setting to default OS "Other".