This is an archive of the discontinued LLVM Phabricator instance.

Fix bug in MachineInstr::hasPropertyInBundle
ClosedPublic

Authored by mikael on Sep 3 2018, 7:50 AM.

Details

Summary

The MCID::Flag enumeration now has more than 32 items, this means that
the hasPropertyBundle argument 'Mask' can overflow.

This patch changes the argument to be 64 bits instead.

Diff Detail

Repository
rL LLVM

Event Timeline

mikael created this revision.Sep 3 2018, 7:50 AM
svenvh added a subscriber: svenvh.Sep 3 2018, 7:52 AM

I don't have much experience with this code, so adding more potential reviewers.
It should be possible to show the failure with a test if we're overflowing?

I'm not sure it can be reproduced in an in-tree target. But it is easy to give you an example when this happens:

You would need a target that uses bundle instructions and uses one of the flags 'Convergent', 'Trap' or 'Add'. If you call e.g MachineInstr.h:isConvergent on bundles the issue occurs.

Following the code path for isConvergent leads us to the following code snippet:

// MCFlag == 32 because Convergent == 32
return hasPropertyInBundle(1ULL << MCFlag, Type);

The resulting value of the shift does not fit in the 'Mask' argument.

bjope added a subscriber: bjope.Sep 4 2018, 2:58 AM

It seems reasonable to match the type of llvm::MCInstrDesc::getFlags() which is uint64_t nowadays. The hasPropertyInBundle method is private to MachineInstr, and afaict only used from MachineInstr::hasProperty. This is kind of a no-brainer to me, and I think we do not need a regression test here.

Although, one idea is to add an assert that MCFlag<64 in MachineInstr::hasProperty.
Another idea could be to add an assert that "Mask != 0" in MachineInstr::hasPropertyInBundle.
And maybe we should have a static (compile time) assert somewhere that the highest value in MCID::Flag is less than 64.

So I think this patch looks good as-is. But feel free to for example add the assert on MCFlag<64 in MachineInstr::hasProperty. I assume that could have helped in detecting this fault?

A small NIT on the first line in the commit message is that it usually is written in "imperative mood" (see https://chris.beams.io/posts/git-commit/#imperative). I don't say that it is mentioned in the dev policy (https://llvm.org/docs/DeveloperPolicy.html#commit-messages) but I think it is common practice.

bjope accepted this revision.Sep 4 2018, 2:58 AM
This revision is now accepted and ready to land.Sep 4 2018, 2:58 AM
mikael updated this revision to Diff 163794.Sep 4 2018, 6:08 AM
mikael retitled this revision from Fixed bug in MachineInstr::hasPropertyInBundle to Fix bug in MachineInstr::hasPropertyInBundle.

Updated the patch to include suggestions from @bjope

bjope added inline comments.Sep 4 2018, 6:16 AM
include/llvm/CodeGen/MachineInstr.h
587 ↗(On Diff #163794)

Asserts should include an error message (see https://llvm.org/docs/CodingStandards.html#assert-liberally).

I think that something like this

`assert(MCFlag < 64 && "MCFlag out of range for bit mask in getFlags/hasPropertyInBundle.");`

also would explain why we require the value to be below 64.

mikael updated this revision to Diff 163814.Sep 4 2018, 7:33 AM
mikael edited the summary of this revision. (Show Details)

Added the suggested assertion comment.

@bjope, are you happy with the last diff?

bjope accepted this revision.Sep 5 2018, 11:24 PM

@bjope, are you happy with the last diff?

Yes, LGTM.

Do you have commit access, or do you need help with landing this?

I don't have commit access yet, I would like to have it at some point, but for now I'd be happy if someone could push it for me.

svenvh added a comment.Sep 6 2018, 1:18 AM

Sure, I'll push it.

This revision was automatically updated to reflect the committed changes.