[llvm-bugs] [Bug 31393] New: New verifier complaining about bad TBAA metadata created during hoist-merge optimization

[via llvm-bugs]

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

            Bug ID: 31393
           Summary: New verifier complaining about bad TBAA metadata
                    created during hoist-merge optimization
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: Kevin.Harris at unisys.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 17760
  --> https://llvm.org/bugs/attachment.cgi?id=17760&action=edit
Bitcode example file

In revs 289402 & 289403 (9-Dec-16), a new TBAA verifier was introduced.  This
new verifier detected a problem with TBAA nodes that are initially OK, but,
after multiple loads or stores are hoisted out of a loop and merged, no longer
pass verification.  Here's an example of the messages produced:

kharris at cm-mariner35:~/dyntrans/Tests/regression> $LLVMPATH/opt -O2 -o
if200014004000_1-o.bc if200014004000_1.bc
Access type node must be scalar
  %grsval = load i64, i64* %saddr266, align 8, !tbaa !47
!47 = !{!2, !2, i64 0}
!2 = !{!3, !3, i64 0}
Access type node must be scalar
  store i64 %mem_grs271, i64* %daddr267, align 8, !tbaa !47
!47 = !{!2, !2, i64 0}
!2 = !{!3, !3, i64 0}
LLVM ERROR: Broken function found, compilation aborted!

The original code has been working for several years.  Historically, when two
loads with different TBAA metadata values are merged, the metadata for the
merged node is the common root of the originals.  The new code appears to
attempt to hold on to both original values (noble), but the new verifier
rejects this structure.  It isn't obvious whether the fix lies in the verifier
or in the merging code, since removing the verification causes a downstream
crash.

We applaud the effort (since reverting to the root node causes the merged load
to potentially interfere with unrelated memory addresses), but not at the
expense of the ability to generate usable code.

We would really appreciate it if this problem could be fixed in time for the
4.0 release.

-- 
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/20161215/2c76e58e/attachment-0001.html>