This is an archive of the discontinued LLVM Phabricator instance.

Don't report the error when non-dangerous load/store is in branch delay slot
ClosedPublic

Authored by sstankovic on Jun 6 2014, 2:18 PM.

Details

Summary

[mips] Fix a bug - Don't report the error when non-dangerous load/store is in branch delay slot.

Diff Detail

Event Timeline

sstankovic updated this revision to Diff 10191.Jun 6 2014, 2:18 PM
sstankovic retitled this revision from to Don't report the error when non-dangerous load/store is in branch delay slot.
sstankovic updated this object.
sstankovic edited the test plan for this revision. (Show Details)
sstankovic added a reviewer: mseaborn.
sstankovic added subscribers: Unknown Object (MLST), petarj.
mseaborn added inline comments.Jun 6 2014, 3:30 PM
lib/Target/Mips/MCTargetDesc/MipsNaClELFStreamer.cpp
171

I don't get why you've reordered this chunk of code. Surely the ordering doesn't matter, because Inst can't be both a call and a memory access on MIPS, can it?

sstankovic added inline comments.Jun 6 2014, 4:31 PM
lib/Target/Mips/MCTargetDesc/MipsNaClELFStreamer.cpp
171

If for the load/store or stack change instruction the condition (MaskBefore || MaskAfter) is false, then in the original ordering the code would first unnecessary check whether the instruction is call (it isn't), and then would check whether the instruction is in the branch delay slot ("if (PendingCall)"). With the ordering in the patch, the unnecessary check whether the instruction is call is avoided.

mseaborn added inline comments.Jun 6 2014, 4:46 PM
lib/Target/Mips/MCTargetDesc/MipsNaClELFStreamer.cpp
171

I don't get it. Surely if you have an instruction for which "IsMemAccess || IsSPFirstOperand" is true but "MaskBefore || MaskAfter" is false, then the "isCall(Inst.getOpcode(), &IsIndirectCall)" check is going to get executed regardless of the ordering of these two chunks of code? Is that what you mean?

Can you restore the original ordering to make the correctness fix clearer, please?

If I've misunderstood this, and the ordering affects compile time (or code clarity), could you do the reordering as a separate change?

sstankovic added inline comments.Jun 6 2014, 5:14 PM
lib/Target/Mips/MCTargetDesc/MipsNaClELFStreamer.cpp
171

What I wanted is basically this: since only the case for load/store or stack change instruction has fall-through path (the cases for jumps and calls both end with a return instruction), I wanted the code that is executed in the fall-through case to be right below it. But OK, I'll restore the original ordering in the patch. As for new ordering, the code should probably first check whether the instruction is load/store (since usually there are more loads/stores than calls or jumps in a function), then check for call and at the end check for indirect jump.

sstankovic updated this revision to Diff 10201.Jun 6 2014, 5:29 PM

I restored the orignal ordering.

mseaborn edited edge metadata.Jun 6 2014, 6:06 PM

Thanks. It's a lot clearer what the change is now. LGTM.

sstankovic accepted this revision.Jun 9 2014, 8:06 AM
sstankovic added a reviewer: sstankovic.
This revision is now accepted and ready to land.Jun 9 2014, 8:06 AM
sstankovic closed this revision.Jun 9 2014, 8:06 AM

Committed in r210470.