This is an archive of the discontinued LLVM Phabricator instance.

[msan] Instrument x86 BMI intrinsics.
ClosedPublic

Authored by eugenis on Mar 1 2019, 5:02 PM.

Details

Summary

They simply shuffle bits. MSan needs to do the same with shadow bits,
after making sure that the shuffle mask is fully initialized.

Diff Detail

Event Timeline

eugenis created this revision.Mar 1 2019, 5:02 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMar 1 2019, 5:02 PM
Herald added subscribers: Restricted Project, hiraditya. · View Herald Transcript
vitalybuka accepted this revision.Mar 1 2019, 5:55 PM
This revision is now accepted and ready to land.Mar 1 2019, 5:55 PM
This revision was automatically updated to reflect the committed changes.

The added test is failing for me because I'm building (and testing) compiler-rt with Clang 7 which doesn't instrument BMI, and I'd assume the same with Clang 8 once released. Is that an oversight or is this configuration expected to break?

lib/msan/tests/msan_test.cc
4653

Shouldn't this be return b & kBmi12Mask? The current expression should always cast to true...

eugenis marked an inline comment as done.Mar 11 2019, 5:16 PM

This is expected to break. I'm surprised it did not break earlier - we often do a compiler change and corresponding integration tests in compiler-rt as a single commit, or two consecutive commits.

lib/msan/tests/msan_test.cc
4653

Of course! Will fix.

This is expected to break. I'm surprised it did not break earlier - we often do a compiler change and corresponding integration tests in compiler-rt as a single commit, or two consecutive commits.

I'm running that configuration for years and it always worked. Do you have a change at hand that did such compiler change?

I'm running that configuration for years and it always worked. Do you have a change at hand that did such compiler change?

Do you run msan lit tests? This is an example where new compiler behavior is tested the same change list, less than a year ago:
https://reviews.llvm.org/rL332761

I'm running that configuration for years and it always worked. Do you have a change at hand that did such compiler change?

Do you run msan lit tests? This is an example where new compiler behavior is tested the same change list, less than a year ago:
https://reviews.llvm.org/rL332761

Yes, I'm running check-all which includes the lit tests. However they are different in that they use the just-built clang executable which will include the fixes to the instrumentation passes. The unit tests are built with the host compiler (Clang 7 in my case) which obviously doesn't work.

Is there a reason the added test needs to be a unit test instead of a new lit test?

As far as I can see, "unit" tests in lib/msan/tests also use the freshly built compiler through msan_compile / clang_compile cmake macros. Otherwise this CL would break everyone's builds.

Both standalone and in-tree use cases seem to be handled, as long as you pass correct COMPILER_RT_TEST_COMPILER to cmake.
What are you doing differently?

Hahnfeld marked an inline comment as done.Mar 15 2019, 3:15 AM

Okay, the test failure is related to my Intel Westmere system (yeah, that's old, I know) where I see:

b = 0x13c0
kBmi12Mask = 0x108

Even the "corrected" code only checked that at least one bit is set :-(

Apologies for running into the wrong direction!

lib/msan/tests/msan_test.cc
4653

Actually the code was still wrong: I've changed this to return (b & kBmi12Mask) == kBmi12Mask in rL356242 which fixes my test failures.