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

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181106/320f995c/attachment.html>

> 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

First off, awesome project! I love it. Comments inline...

On Tue, Nov 6, 2018 at 5:59 PM 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.
>
Check out a similar pass in the X86
backend: llvm/lib/Target/X86/X86PadShortFunction.cpp

You'll likely need to use MachineLoopInfo to find the loops.

-Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181106/68e616c8/attachment.html>