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: unassignedb...@nondot.org
Reporter: matthew.arsena...@amd.com
CC: llvm-bugs@lists.llvm.org, quentin.colom...@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
