MOVZ/MOVN does not gives correct code.

[nihilus]

@hlide any clues why this is so?

[hlide]

did you fix the issue?

[nihilus]

No... :-( I am going to bed now.

[hlide]

Ok, can you elaborate what the issue is exactly and in which context (for instance, MOVZ/N are systematically wrong or just inside a delay slot? etc.).

[nihilus]

The statements does not generate the move function. So it is generally broken. And in a delayslot after a JR it will not generate the statement before the JR but in a separate function.

[nihilus]

403dbc: jalr $t9
403dc0: movn $a0, $a3, $v0

gives the following 'extra function':

void fun_403dc0() {
    int32_t v0_1;

    if (!v0_1) 
        goto "???";
}

[nihilus]

403604: move $v1, $zero
403608: addiu $v1, $zero, 2
40360c: addiu $v0, $zero, 1
403610: movz $v1, $v0, $a0
403614: jr $ra

just generates the return-statement.

[hlide]

snowman tends to discard a lot of values in a function.

I think snowman doesn't understand movn is setting the first function argument (a0) conditionally BEFORE calling the function given in t9 in:

403dbc: jalr $t9
403dc0: movn $a0, $a3, $v0

that is,

if (v0) t9(a0 = a3); else t9(a0);

-->

if (v0) t9(a3); else t9(a0);

and we have a similar issue but with return value being a 64-bit integer (v1:v0), the v1 of which is also set conditionally BEFORE the return. It should have been:

v1 = 2; v0 = 1; if (a0) return LLONG(v1,v0); else LLONG((v1 = v0),v0);

-->

if (a0) return 0x000000200000001ULL; else return 0x0000000100000001ULL;

[nihilus]

@hlide that's why I implemented addNonVolatileRegister() :-) Then it won't discard so those registers.

[nihilus]

I guess part of the problem is for fixing when it is a delay slot.

[nihilus]

@hlide I can see the logic is correct however if you wanna try this I suggest you use 'tuxera.bench' (BE MIPS-I)

[nihilus]

I improved the code generation in 8be261d

[nihilus]

@hlide actually when there is a jump statement in the delay slot like having MOVN/MOVZ in a delay slot, the generated code will not come before the branching but in a separate function. Any clues? This is not specific for MOVN/MOVZ but for jumps to a 'MipsExpressionFactoryCallback'