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: unassignedb...@nondot.org
Reporter: kevin.har...@unisys.com
CC: llvm-bugs@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@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
