[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


            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;

  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

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

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