This is an archive of the discontinued LLVM Phabricator instance.

[Sparc] Leon Errata Fix Passes
AbandonedPublic

Authored by lero_chris on Aug 12 2016, 10:49 AM.

Details

Summary

Errata fixes for various errata in different versions of the Leon variants of the Sparc 32 bit processor.

The nature of the errata are listed in the comments preceding the errata fix passes. Relevant unit tests are implemented for each of these.

Note, I won't be able to see any response comments until after 30th August 2016, so please don't expect any immediate responses.

Diff Detail

Repository
rL LLVM

Event Timeline

lero_chris retitled this revision from to [Sparc] Leon Errata Fix Passes.
lero_chris updated this object.
lero_chris set the repository for this revision to rL LLVM.
lero_chris added a subscriber: llvm-commits.

Removed change to length of supported atomics for LEON processors. Should have always been 32 bit and the previous change wasn't necessary in SparcISelLowering.cpp

dcederman added inline comments.Aug 13 2016, 1:25 AM
lib/Target/Sparc/LeonFeatures.td
14–85

The above changes are not related to the errata fixes. You should move them to a separate patch.

lib/Target/Sparc/LeonPasses.cpp
918–955

Truncating the immediate will cause the call to go to the wrong address, so this is not a valid fix.

The errata also only applies to the CALL instruction, not CALLrr or CALLri, which are pseudo instructions that map to JMPL.

You instead need to check for CALL instructions with bit 24 = 1 and bit 21 = 0, or any CALL instruction where the address is resolved in the linker stage, and build a new call using SETHI and CALLri instead of CALL.

962–963

Is it required? I cannot see that those instruction are generated by the compiler or any overflow bit checks.

1015–1020

This does not do what you want it to do. Please try it on hardware.

1061

The errata is for single-word floats so you should change that to LDFri and LDFrr.

lib/Target/Sparc/Sparc.td
25

There are several unrelated changes in this file. Please move them to a separate patch.

lib/Target/Sparc/SparcISelLowering.cpp
27

Same with this file. Move the unrelated changes to a separate patch.

test/CodeGen/SPARC/LeonConvertDoubleFPToSingleFPInstrUT.ll
1–4 ↗(On Diff #67860)

Unrelated.

lero_chris updated this revision to Diff 70060.Sep 1 2016, 1:08 PM

Update to reviewed code to address comments.

Addresses some of the review comments.

lib/Target/Sparc/LeonFeatures.td
14–85

There were some formatting changes to existing code. I've removed these. The remainder are specific to this change.

lib/Target/Sparc/LeonPasses.cpp
877

Implemented with SETHI and CALLri, per suggestions.

877

This is per the design we've been working off. Do you suggest we remove this pass if it's not required?

877

There are other NOP insertion passes in this file for single float instructions, but this is specifically to address problems with double float instructions. Are you sure this should be for singles?

lib/Target/Sparc/Sparc.td
25

Removed formatting changes.

lib/Target/Sparc/SparcISelLowering.cpp
27

Removed formatting changes.

dcederman requested changes to this revision.Sep 2 2016, 4:38 AM
dcederman edited edge metadata.

One of the passes generates this instruction, "wr %g0, 1, %psr", which tells me that it has not been tested. You should make sure that the errata fixes do not break the resulting program. I would recommend reading up on the psr register and how it is used before attempting to modify it.

I have plenty of other comments, but you really should test the code before submitting it for review.

This revision now requires changes to proceed.Sep 2 2016, 4:38 AM
lero_chris updated this revision to Diff 70169.Sep 2 2016, 8:51 AM
lero_chris edited edge metadata.

Removed the IgnoreZeroFlag erratum fix pass containing "wr %g0, 1, %psr" as this pass does not have any effect.

The compiler, including this pass was tested through 6600 tests in a test suite on the processor and through unit tests which tested that the code was generated given the specific input pattern, so if these all passed, we can safely assume that the erratum that this pass was intended to fix can never be generated by LLC.

Hi,

It is hard to review this since you are mixing formatting changes, fixes to old passes, and new passes. I suggest that you update this revision so that it only contains the new passes (ReplaceSDIV, FixCALL, InsertNOPDoublePrecision, PreventRoundChange, InsertNOPsLoadStore) and their corresponding unit tests. The fixes to old passes and the formatting changes should be in separate patches.

You should also make sure that your code is actually used by your tests. You discovered now that IgnoreZeroFlag was not used anywhere and removed it, but what about FixCALL? Or ReplaceSDIV? Are they used?

Hi, The formatting changes that were *entirely* unrelated to the code updates have been removed. As part of the review process, I also removed all the inline ASM code,m as requested by James Knight. Otherwise, the changes are all specifically to do with the updated passes, except some very small changes to comments and formatting *entirely in and around code that has been changed as part of this update*.

This review really needs to be completed this Friday, so we really need all appropriate comments by then or these changes simply will not be able to be completed before I move to a different employer.

Please focus comments on breaking changes. If there are none, I need to get this code checked-in. Comments on code improvement must come later at this stage and there may be time for improvements later on if we can get this base-line checked-in.

If you want to speed up the reviewing process you should split up the patches. For example, setMaxAtomicSizeInBitsSupported and useSoftFpu should not be included here.

The removal of the inline asm part could be its own, easy to accept, patch.

And, as I asked before, have you made sure that your code is actually tested by your tests? The unit tests that you have included does not seem to be related to the new passes.

lib/Target/Sparc/LeonPasses.cpp
63–85

This does not seem to be the right way to get a free register if it means that you could get G7 back as a work register. That register and others are reserved for the OS and could mess things up if changed.

And what do you do if no register is available?

951

Here you need to handle the case when getUnusedIntRegister returns -1

lero_chris abandoned this revision.Oct 17 2016, 1:49 AM

This review has been separated into seperate reviews. Abandoning this as an open review.