[llvm-bugs] [Bug 48209] New: Incorrect propagation of noalias metadata in InlineFunction.

[via llvm-bugs]

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

            Bug ID: 48209
           Summary: Incorrect propagation of noalias metadata in
                    InlineFunction.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Transformation Utilities
          Assignee: unassignedbugs at nondot.org
          Reporter: xur at google.com
                CC: llvm-bugs at lists.llvm.org, xur at google.com

Created attachment 24177
  --> https://bugs.llvm.org/attachment.cgi?id=24177&action=edit
A test that shows we get undef code

commit 27f647d117087ca11959e232e6443f4aee31e966
[Inliner] Consistently apply callsite noalias metadata
seg-faults one of the our programs.

I'm not sure if the patch is correct -- it propagates the noalias metadata
from the callsite to the argument definition. 

In our program, the argument definition defines the same alias.scope. The patch
will append !noalias metadata to the instruction with the same set of
!alias.scope.

We get:

%27 = load %"class.std::__cfi::__shared_weak_count"*,
%"class.std::__cfi::__shared_weak_count"** %26, align 8, !alias.scope !46635,
!noalias !46635

This is problematic. For this particular case, this load depends on a memset
which has the same alias group. With the noalias metadata added, alias query
skips the memory, and the dependent instruction becomes the memory allocation.
GVN has a rule that simplifies direct load the memory allocation to undef. The
generated code seg-faults.

I'm attaching a simplified test here.

-- 
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/20201118/d18f9843/attachment.html>