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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

David Jones via llvm-dev
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.

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

David Jones via llvm-dev


> On 7 Nov 2018, at 09:59, Dan Ravensloft via llvm-dev <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

David Jones via llvm-dev
In reply to this post by David Jones via llvm-dev
First off, awesome project! I love it. Comments inline...

On Tue, Nov 6, 2018 at 5:59 PM Dan Ravensloft via llvm-dev <[hidden email]> 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 

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev