BTW I've noticed you only track constants with register allocation, when they are evicted it's lost, which is a shame. Quite often I see large functions that load a pointer to scratchpad at their start, and access it throughout; but then it's register gets evicted and reloaded shortly, and those accesses can no longer be resolved at compile time.
I actually fixed that in yabause (see
this patch). It would be possible to do it for MIPS emulation too. It wasn't a huge improvement, and only affected a small number of cases, which is why I haven't put a lot of effort into it.
Then there is a problem with those resolved accesses that the address is reloaded before each access needlessly, it could modify previous instead or use offset of ARM ldr instruction.
Yes, that's a problem. I suppose it would be possible to keep track of what values are in which ARM registers and not reload values if they're already there.
I could try to change this but almost every change I do to register allocator or addressing stuff results in some real nasty regressions, that show up in 1/20 of games or so. I wish your recompiler was easier to work with *sigh*.
Early on I made some design decisions that in hindsight weren't the best way to do things, but I didn't know that at the time. The constant propagation is one of those things. When a constant is loaded into a MIPS register, you have to put the value into an ARM register and then write it out, so I only kept track of constants that went into ARM registers. To really do it properly, you need to keep track of two separate states - one, when the virtual MIPS registers actually get updated with the proper values, and two, what values those registers are supposed to have, which are used to precalculate memory addresses even if the MIPS register is no longer assigned to an ARM register.
BTW, I think your assessment of the dyna_linker bug is correct. I'm surprised that could happen, but only because new_recompile_block is so large that it will usually push everything else out of the L1 cache. Apparently in rare cases it does not (although I've never seen it). A sure fix would be to have dyna_linker flush the cache, although I think what you did will work. Another possibility would be to not add the duplicate entries to jump_in[].