This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
- From: "kcc at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 10 Sep 2015 17:14:58 +0000
- Subject: [Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
- Auto-submitted: auto-generated
- References: <bug-67513-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513
--- Comment #5 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Yury Gribov from comment #1)
> (In reply to Andrey Ryabinin from comment #0)
> > (shadow value is usually zero).
>
> What makes you think so? AFAIU for less-than-8-byte scalars it's always
> non-zero. I vaguely remember than Kostya did something like this in Clang
> case and it resulted in negligeable improvement.
The code in llvm uses branch weights to indicate that the slow path
is rarely taken.
if (ClAlwaysSlowPath || (TypeSize < 8 * Granularity)) {
// We use branch weights for the slow path check, to indicate that the slow
// path is rarely taken. This seems to be the case for SPEC benchmarks.
TerminatorInst *CheckTerm = SplitBlockAndInsertIfThen(
Cmp, InsertBefore, false, MDBuilder(*C).createBranchWeights(1,
100000));
The measurements were done on SPEC 2016 loooong ago,
I have no idea whether this is still a good heuristic.
I remember that the difference was not huge, but enough to justify
one extra parameter.