Potential `nop` generating bug

[bismurphy]

I was working on a function for Castlevania:SOTN and I seem to have a nop in the Target that won't generate with maspsx, but does generate with aspsx.

Decomp.me scratch is here: https://decomp.me/scratch/RVSDy

The missing nop is at ASM line 458.

If I change the compiler to PSYQ3.5, then the nop instruction is emitted, but the default SOTN preset (gcc 2.6.3 + maspsx) does not generate that NOP.

Maybe this isn't a maspsx issue, but it feels like one, since the single instruction differs here. My function mismatches in other ways, but this nop jumped out at me as something you may want to look into. Presumably this is related to the fact that instruction 454 is a lw targeting the s1 register, and then 45c is a lh loading from an offset of that s1 pointer.

[mkst]

Interestingly enough, the nop is present without the -gcoff flag, so maspsx isnt handling all the extra noise that -gcoff adds. Hopefully easy to fix.

with -Wa,--print-output and -gcoff:

LM135:
lw  $17,124($fp)
#nop # DEBUG: '$Lb8:' does not load from $17
$L38:

.loc    2 170
LM136:
$Lb8:
lh  $3,8($17)

with -Wa,--print-output but without -gcoff:

lw  $17,124($fp)
$L38:
nop # DEBUG: Reuse of '$17'. 'lh    $3,8($17)' does not use $at
# $L38:  # DEBUG: skipped
lh  $3,8($17)

Edit: I reckon looking for Le or Lb in is_label is the solution. Will test in a couple of hours and release if it solves it - thanks for raising the issue!

def is_label(line: str):
    return re.match(r"\$Le?\d+:$", line)

[bismurphy]

Will test in a couple of hours and release if it solves it - thanks for raising the issue!

Awesome, thanks as always! Really appreciate how much you help with everything.