This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]