[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


            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
). 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

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