[llvm-bugs] [Bug 38062] New: Using -exhaustive-register-search may lead to assert (RAGreedy)

[via llvm-bugs]

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

            Bug ID: 38062
           Summary: Using -exhaustive-register-search may lead to assert
                    (RAGreedy)
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: verena at codeplay.com
                CC: llvm-bugs at lists.llvm.org

When using the option -exhaustive-register-search and a low (or default) value
of -lcr-max-interf you may get the assertion `(i == Size || Traits::stopLess(b,
start(i))) && "Overlapping insert".
This is due to RAGreedy::mayRecolorAllInterferences:

    if (Q.collectInterferingVRegs(LastChanceRecoloringMaxInterference) >=
        LastChanceRecoloringMaxInterference && !ExhaustiveSearch) {
      DEBUG(dbgs() << "Early abort: too many interferences.\n");
      CutOffInfo |= CO_Interf;
      return false;
    }
    for (unsigned i = Q.interferingVRegs().size(); i; --i) {
      ...

If ExhaustiveSearch is set then we loop through the interfering registers to
recolour them. But if LastChanceRecoloringMaxInterference is set to a number
lower than the actual number of interferences then we only process (deallocate)
a subset. When we then allocate the original interval we have introduced an
illegal overlap.

I feel -exhaustive-register-search should imply -lcr-max-interf=inf or at least
print a useful error message. I'm guessing without assertions enabled this
might just lead to wrong codegen.

I'm afraid my target is custom, so I can't provide a test case.

-- 
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/20180705/986d22f3/attachment.html>