This is an archive of the discontinued LLVM Phabricator instance.

hwasan: Move fixed shadow behind opaque no-op cast as well.
ClosedPublic

Authored by pcc on Oct 29 2020, 1:55 PM.

Details

Summary

This is a workaround for poor heuristics in the backend where we can
end up materializing the constant multiple times. This is particularly
bad when using outlined checks because we materialize it for every call
(because the backend considers it trivial to materialize).

As a result the field containing the shadow base value will always
be set so simplify the code taking that into account.

Depends on D90424

Diff Detail

Event Timeline

pcc created this revision.Oct 29 2020, 1:55 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 29 2020, 1:55 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
pcc requested review of this revision.Oct 29 2020, 1:55 PM
hctim added a comment.Oct 29 2020, 4:34 PM

LGTM but will let eugenis make the approval as he's much better versed here.

llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
588–593

should this be getShadowNonTls now (and getShadowIfunc() above)?

eugenis accepted this revision.Oct 29 2020, 4:40 PM

LGTM

llvm/test/Instrumentation/HWAddressSanitizer/basic.ll
60

This seems suboptimal in the zero shadow case. But is it even used anywhere?

This revision is now accepted and ready to land.Oct 29 2020, 4:40 PM
pcc added inline comments.Oct 30 2020, 1:05 PM
llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
588–593

I'll rename this one. It's still dynamic in the case where there is an ifunc so I left the other one as is.

llvm/test/Instrumentation/HWAddressSanitizer/basic.ll
60

I don't believe that it is. But I think that even with zero shadow we would want a single mov x20, xzr at the top of the function rather than repeating it for every memory access.

This revision was landed with ongoing or failed builds.Oct 30 2020, 1:24 PM
This revision was automatically updated to reflect the committed changes.