[llvm-bugs] [Bug 28931] New: size optimization: avoid stack adjustments after __asan_report_loadN

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Aug 10 16:33:21 PDT 2016


https://llvm.org/bugs/show_bug.cgi?id=28931

            Bug ID: 28931
           Summary: size optimization: avoid stack adjustments after
                    __asan_report_loadN
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider:
int many_loads(int *a, int *b, int *c, int *d) {
  int s = 0;
  s += *a;
  s += *b;
  s += *c;
  s += *d;
  return s;
}

We generate many sequences like:
        pushl   %eax
        calll   ___asan_report_load4
        addl    $4, %esp   # DEAD CODE
        #APP
        #NO_APP
...
        pushl   %edx
        calll   ___asan_report_load4
        addl    $4, %esp   # DEAD CODE
        #APP
        #NO_APP
...
        pushl   %ecx
        calll   ___asan_report_load4
        addl    $4, %esp  # DEAD CODE
        #APP
        #NO_APP

LLVM can't do this easily because __asan_report_* isn't marked noreturn to
avoid tail merging it and hurting ASan debuggability. Perhaps we should fix the
debugging problem, and then LLVM can exploit the noreturn knowledge to fix this
issue.

Alternatively, we could just mark the entire __asan_report_* API as __stdcall
or __fastcall.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160810/09392798/attachment.html>


More information about the llvm-bugs mailing list