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.
Differential D18995
[mips] Fix emitAtomicCmpSwapPartword to handle 64 bit pointers correctly zoran.jovanovic on Apr 11 2016, 3:24 PM. Authored by
Details 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
Event TimelineComment Actions
I'll be submitting a patch for that once I've addressed some test failures from lnt execution. Comment Actions 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. Comment Actions 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. Comment Actions 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). Comment Actions 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.
Comment Actions To be clear, my comments are referring to Diff 53326 and not the latest version which was uploaded before I clicked 'submit'
Comment Actions New patch version. Comment Actions LGTM with a couple small changes
|