[llvm-bugs] [Bug 39546] New: Improve alias analysis by checking for known callsites
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Nov 2 17:15:00 PDT 2018
https://bugs.llvm.org/show_bug.cgi?id=39546
Bug ID: 39546
Summary: Improve alias analysis by checking for known callsites
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedbugs at nondot.org
Reporter: david.bolvansky at gmail.com
CC: llvm-bugs at lists.llvm.org
#include <string.h>
void alias(char * s, char * p) {
strcpy(s,p); // s,p cannot alias since it would be UB
p[3] = *s;
p[4] = *s;
}
GCC:
alias:
push rbx
mov rbx, rsi
call strcpy
movzx eax, BYTE PTR [rax]
mov BYTE PTR [rbx+3], al
mov BYTE PTR [rbx+4], al
pop rbx
ret
Clang -O3:
alias: # @alias
push r14
push rbx
push rax
mov r14, rsi // btw, this is a weird issue
mov rbx, rdi
call strcpy
mov al, byte ptr [rbx]
mov byte ptr [r14 + 3], al
mov al, byte ptr [rbx] // useless reload
mov byte ptr [r14 + 4], al
add rsp, 8
pop rbx
pop r14
ret
So idea:
We have ptr P and Q. If P and Q are used as in a call site (*) where aliasing
would be UB, alias analysis can just bail out with noalias answer.
* strcpy, strncpy, memcpy, bcopy.. maybe even s(n)printf
--
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/20181103/22e3560b/attachment.html>
More information about the llvm-bugs
mailing list