[llvm-bugs] [Bug 33074] New: Rematerialized LEApcrel can address a different literal pool from the original

[via llvm-bugs]

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

            Bug ID: 33074
           Summary: Rematerialized LEApcrel can address a different
                    literal pool from the original
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: john.brawn.123 at gmail.com
                CC: llvm-bugs at lists.llvm.org

When we have an LEApcrel instruction that gets rematerialized, if the
rematerialization point is far enough away from the original then the literal
pool for the first LEApcrel will be emitted before we get to the second
LEApcrel causing the second LEApcrel to be redirected to a new literal pool
which will be emitted later. This means the two LEApcrel instructions give
different values, which can lead to incorrect program behaviour in some cases.

An example:

file1.c:
  #include <stdio.h>
  static const char *staticstr = 0;
  void otherfn1(const char *p, const char *q)
  {
    if (p != staticstr) printf("p != staticstr\n");
    if (q != staticstr+8) printf("q != staticstr+8\n");
  }
  void otherfn2(const char *p)
  {
    staticstr = p;
  }
  void filler(void)
  {

  }

file2.c:
  void otherfn1(const char *p, const char *q);
  void otherfn2(const char *p);
  void filler(void);
  void fn(int *p)
  {
    const char *str = "expected";
    otherfn2(str);

    // Use up a load of registers, causing str to spill
    int arr[8];
    arr[0] = p[0];
    arr[1] = p[10];
    arr[2] = p[20];
    arr[3] = p[30];
    arr[4] = p[40];
    arr[5] = p[50];
    arr[6] = p[60];
    arr[7] = p[70];
    filler();
    p[0] = arr[0];
    p[10] = arr[1];
    p[20] = arr[2];
    p[30] = arr[3];
    p[40] = arr[4];
    p[50] = arr[5];
    p[60] = arr[6];
    p[70] = arr[7];

    // Add a load of filler to make the literal pool out of range
  #define FILLER8 filler(); filler(); filler(); filler(); filler(); filler();
filler(); filler();
  #define FILLER64 FILLER8; FILLER8; FILLER8; FILLER8; FILLER8; FILLER8;
FILLER8; FILLER8;
  #define FILLER512 FILLER64; FILLER64; FILLER64; FILLER64; FILLER64; FILLER64;
FILLER64; FILLER64;
    FILLER512;
    FILLER512;

    otherfn1(str, str+8);
  }
  int main()
  {
    int arr[80];
    fn(arr);
    return 0;
  }

Compiled with -mcpu=cortex-a15 -mthumb -O2 we get the output
  p != staticstr
  q != staticstr+8
because for the call to otherfn1 the LEApcrel of "expected" has been
rematerialized, causing the address to be different to the call to otherfn2.

-- 
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/20170517/6457918a/attachment.html>