[llvm-dev] [RFC] Working around a PS2 hardware errata

[Dean Michael Berris via llvm-dev]

> On 7 Nov 2018, at 09:59, Dan Ravensloft via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> The MIPS R5900 core that powers the PlayStation 2's CPU has a hardware bug that affects very short loops of 6 or less instructions where the processor may fail to branch under "special conditions" (don't you love vague hardware manuals?)
> 
> The obvious solution is to pad the loop with NOPs so that it is bigger than 6 instructions long.
> 
> However, I have a few questions to ask about this.
> 
> First, where would I go about adding a pass that detects and works around this hardware bug? Presumably it would have to go as a pass after instruction selection, but I'm unfamiliar with LLVM internals in this case.
> 

I would think this would be in the assembly printer or MC layer. This would be a lowering decision, which you can do on a per-subtarget basis. In X86 this would be in the AsmPrinter implementation, but that’s special compared to the other back-ends which I think have a more direct function/basic-block lowering implementation.

> Second, assuming I implemented a fix for this, would it get merged upstream? The R5900 isn't a supported processor by either LLVM or GCC, so I could understand some reluctance to merge it, even hidden behind a target feature.

Personally, I would think that a special target feature flag might be OK as long as there are no regressions in buildbots. I understand that making a target officially supported is a higher bar, but unless it’s causing major issues elsewhere I don’t see why a localised change like this might not be OK to merge.

That said, I would ask the maintainers of the MIPS backends to concur before proceeding.

Cheers

PS. I think this is awesome! The PS2 has a special place in my heart and most of my younger years were spent on Castlevania Symphony of the Night and Tekken 2. :)

-- Dean