[llvm-bugs] [Bug 25462] New: Alias analysis on function noalias argument attribute inferior to inlined function with scoped-noalias

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Nov 9 12:27:35 PST 2015


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

            Bug ID: 25462
           Summary: Alias analysis on function noalias argument attribute
                    inferior to inlined function with scoped-noalias
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: asb at asbradbury.org
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

See the mailing list discussion at
http://lists.llvm.org/pipermail/llvm-dev/2015-November/091949.html

Consider the simple C program:
#include <stdint.h>
#include <stdio.h>

void main_loop(int len, uint8_t *restrict input_buf, uint8_t *restrict
output_buf) {
  int    i;
  uint8_t a, b, c;

#pragma clang loop unroll_count(8)
  for (i = 0; i < len; i++) {

    a = *input_buf++;
    b = *input_buf++;
    c = *input_buf++;

    a = (uint8_t) (a - 10);
    b = (uint8_t) (b - 20);
    c = (uint8_t) (c - 30);

    *output_buf++ = a;
    *output_buf++ = b;
    *output_buf++ = c;
  }
}

__attribute__((flatten))
void dummy_function(int len, uint8_t *input_buf, uint8_t *output_buf) {
  printf("This function exists just to examine inlining behaviour\n");
  main_loop(len, input_buf, output_buf);
}

Compile with "clang-3.8 -emit-llvm -fno-slp-vectorize -fno-vectorize
--target=mips-linux-gnu -std=c99 -O2 example.c -c" (note the mips-linux-gnu
target is used to avoid attempts at vectorisation, which I can't seem to
disable when targeting x86). This IR is generated: http://pastebin.com/MXpDvUyw

Running the output through opt with basicaa, tbaa and scoped-noalias
(opt-3.8 -basicaa -tbaa -scoped-noalias -aa-eval -analyze
-print-memdeps example.bc) gives the output shown at
http://pastebin.com/Z99NP6A9. You can see that clobber/def
dependencies are shown throughout main_loop despite the noalias
parameter attributes. e.g.:

    Def from:   %28 = load i8, i8* %25, align 1, !tbaa !1
  store i8 %37, i8* %39, align 1, !tbaa !1

    Clobber from:   store i8 %37, i8* %39, align 1, !tbaa !1
  %42 = load i8, i8* %27, align 1, !tbaa !1

When main_loop is inlined, the scoped noalias metadata is added to all relevant
instructions and so we get the full benefit of adding the restrict annotation.
As Hal notes in the linked llvm-dev thread, it seems basicaa will only look
through a single Phi node.

An additional oddity that may indicate a separate bug is that the printed
memory dependence results for dummy_function include a lot of mysterious
'Unknown' dependencies. Even more mysterious: even more mysterious some
'Unknown' dependencies can be associated with a basic block but not others,
despite the code being perfectly regular.

    Unknown in block %.lr.ph.i.preheader
    Unknown in block %.lr.ph.i
  %101 = load i8, i8* %98, align 1, !tbaa !1, !alias.scope !4, !noalias !7

    Unknown
  store i8 %104, i8* %95, align 1, !tbaa !1, !alias.scope !7, !noalias !4

-- 
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/20151109/c4e65714/attachment.html>


More information about the llvm-bugs mailing list