[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