[llvm-bugs] [Bug 39602] New: RegisterCoalescer fails to track lanes properly when speculating ErasableImplicitDef
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Nov 9 08:22:28 PST 2018
https://bugs.llvm.org/show_bug.cgi?id=39602
Bug ID: 39602
Summary: RegisterCoalescer fails to track lanes properly when
speculating ErasableImplicitDef
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Register Allocator
Assignee: unassignedbugs at nondot.org
Reporter: Matthew.Arsenault at amd.com
CC: llvm-bugs at lists.llvm.org, quentin.colombet at gmail.com
Created attachment 21105
--> https://bugs.llvm.org/attachment.cgi?id=21105&action=edit
Reduced testcase
The attached testcase fails with "Couldn't join subrange!" due to the special
handling of implicit_defs. If you replace the IMPLICIT_DEF with a meaningful
value (e.g. S_MOV_B32 -1), it works.
When it assumes it's erasable, it clears out the valid lane set by the
IMPLICIT_DEF in another block
(https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/RegisterCoalescer.cpp#L2505
). This isn't restored when later it's decided the implicit_def isn't really
erasable, resulting in an inconsistent ConflictResolution result. Removing this
clearing entirely works, but breaks testcases where the implicit_def really
should be removed. The cleared lanes are needed to do the rest of the checks in
analyzeValue.
I'm not sure the correct way to fix this. I've tried inserting side tracking of
the original valid lanes, but it doesn't really work. It seems like most of the
work done in analyzeValue should really be done in resolveConflicts when
everything should be known, and I'm not sure why these are split the way they
are currently. I'm also unconvinced this special handling of implicit_def is
worth the complexity. It seems pretty fragile (bug 39542 was derived from the
same testcase), so maybe either implicit_def should always be left, or the
cross block restriction removed?
--
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/20181109/5265e9b4/attachment.html>
More information about the llvm-bugs
mailing list