This is an archive of the discontinued LLVM Phabricator instance.

[mips] Fix emitAtomicCmpSwapPartword to handle 64 bit pointers correctly
ClosedPublic

Authored by zoran.jovanovic on Apr 11 2016, 3:24 PM.

Details

Summary

Updated revision of: http://reviews.llvm.org/D13649

Test atomic.ll modified because MipsInstrInfo::getEquivalentCompactForm does not handle mips64r6 instructions. Support should be added in separate patch.

Diff Detail

Repository
rL LLVM

Event Timeline

zoran.jovanovic retitled this revision from to [mips] Fix emitAtomicCmpSwapPartword to handle 64 bit pointers correctly.
zoran.jovanovic updated this object.
zoran.jovanovic added a subscriber: llvm-commits.

Test atomic.ll modified because MipsInstrInfo::getEquivalentCompactForm does not handle mips64r6 instructions. Support should be added in separate patch.

I'll be submitting a patch for that once I've addressed some test failures from lnt execution.

petarj added a subscriber: petarj.Apr 12 2016, 6:29 AM
mpf added a subscriber: mpf.Apr 12 2016, 9:16 AM

The changes in this patch look like they go too far. The issue was about pointer size not integer size. The only pseudo that needs to be i64 is alignedaddr when pointers are 64-bit and the only operation that needed to change was the AND that calculates alignedaddr. The rest should (and I believe must) stay as i32 as the values are used alongside LL/SC which operate on i32 types none of the data in this code exceeds 32-bit as it is all about sub-word operations.

As stated in description of the patch it is new revision of: http://reviews.llvm.org/D13649, which was created by Jelena Losic, and all following revisions were based on received comments.
This revision is based on latest set of comments received on http://reviews.llvm.org/D13649.
I do believe that it produces correct output.
Also, I do agree that particular issue can be fixed by only changing type of alignedaddr pseudo to i64 when pointers are 64 bit.
I will prepare new patch version that handles issue in that manner.

New patch version that only changes type of AlignedAddr and uses appropriate AND instruction for calculating value of AlignedAddr (although correct output will be produced with any AND instruction because they all work on register size data - functionally there is no AND32 and AND64).

dsanders edited edge metadata.Apr 13 2016, 3:26 AM

As Matthew mentioned, this new version has gone further than my comments intended. It wasn't my intention to promote every integer operation to i64, just the AND/OR/XOR operations (and my position on these operations needs to change following an off-list discussion about sign-extension on MIPS, see below). The majority should stick to the type of the result of Mips::LL, otherwise the Mips::LL will have incompatible registers attached to the instruction.

The discussion on sign-extension on MIPS has caused us to decide to keep i32 AND/OR/XOR as a legal operation on MIPS64 despite such an operation not existing on MIPS64 implementations. This is because of an architectural requirement for i32 operations to produce i32 results that have been sign-extended to GPR-width. As long as this requirement is met (and there is currently a bug in this area which Vasileios is fixing) then the GPR-width AND/OR/XOR operations will handle i32 values correctly in all cases.

lib/Target/Mips/MipsISelLowering.cpp
1492–1493 ↗(On Diff #53326)

As mentioned in the comments on D13649, we're masking a pointer here so the predicate should use ArePtrs64bit instead of AreInts64bit. Some of the instructions that follow have the same issue (e.g. line 1494, 1498, 1502, etc.)

Similarly, MaskLSB2, PtrLSB2, Off, etc. are a pointer-sized integers and should use the RCp class.

1496–1501 ↗(On Diff #53326)

It's not directly related to this patch but could you mention this optional xor in the above comment that summarizes the instructions the code will produce. It seems we forgot to do this in an earlier change

To be clear, my comments are referring to Diff 53326 and not the latest version which was uploaded before I clicked 'submit'

dsanders added inline comments.Apr 13 2016, 3:53 AM
lib/Target/Mips/MipsISelLowering.cpp
1488–1489 ↗(On Diff #53524)

On N64, this code can produce an AND64 with a GPR64 result, one GPR64 operand (Ptr), and a GPR32 operand (MaskLSB2). This contradicts the instruction definition for AND64 which expects the result and both operands to be GPR64.

Adding -verify-machineinstrs to your llc command will report the places where register classes are used incorrectly. You may also need to use SUBREG_TO_REG or EXTRACT_SUBREG to switch between register classes in some places.

dsanders added inline comments.Apr 13 2016, 5:33 AM
lib/Target/Mips/MipsISelLowering.cpp
1488–1489 ↗(On Diff #53524)

Adding -verify-machineinstrs to your llc command will report the places where register classes are used incorrectly. You may also need to use SUBREG_TO_REG or EXTRACT_SUBREG to switch between register classes in some places.

Sorry, I've made a mistake here. EXTRACT_SUBREG is for an earlier stage of the code generator. At this stage you need to use something like BuildMI(...).addReg(Reg, 0, Mips::sub_32) instead.

zoran.jovanovic edited edge metadata.

New patch version.
Generated code is correct (sd/ld are used to store/restore pointer value).
It passes -verify-machineinstrs for o32, n32 and n64.

dsanders accepted this revision.Apr 13 2016, 7:45 AM
dsanders edited edge metadata.

LGTM with a couple small changes

lib/Target/Mips/MipsISelLowering.cpp
1491–1495 ↗(On Diff #53554)

Both sides are nearly identical. Could you use addReg(Ptr, 0, ArePtrs64bit ? Mips::sub_32 : 0) to avoid the duplication?

test/CodeGen/Mips/atomicCmpSwapPW.ll
1–2 ↗(On Diff #53554)

Please cover the O32 and N32 cases too.

4–5 ↗(On Diff #53554)

Please add checks for the whole sequence and check we use the right instruction variant (-asm-show-inst will make this available to FileCheck).
Given that this patch is urgent and the test currently covers the most important detail, I'm ok with this particular bit being done as a follow-up.

This revision is now accepted and ready to land.Apr 13 2016, 7:45 AM
This revision was automatically updated to reflect the committed changes.