Possible bug in LiveIntervals (triggered on the XCore target)?

Hi again,

Now, after I fixed the graph coloring regalloc bug that was triggered
by the ARM target, I continue testing and found another bug, this time
on the XCore target. First I thought that it is again specific to my
register allocator, but it seems to be trigerred also by LLVM's
linearscan register allocator.

I don't know if the XCore target is stable enough in LLVM, or may be I
should just safely skip it during testing because it is not mature
yet. Anyway, I report it here - may be it is of some interest.

The crash happens in LiveIntervalsAnalysis, inside the spilling
function. From what I observe, I'd say it is related to
rematerializable intervals.

The assertion says:
/opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142:
llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int):
Assertion `I != r2iMap_.end() && "Interval does not exist for
register"' failed.

I attach the BC file generated by bugpoint, so that you can reproduce it.

The command-line I use is:
llc --regalloc=linearscan --march=xcore -f bugpoint-reduced-simplified.bc

Any ideas about the reasons of this bug?

Thanks,
  -Roman

bugpoint-reduced-simplified.bc (524 Bytes)

Please file a bug report. I'll look at it when I find the time.

Evan

Roman Levenstein wrote:

Hi again,

Now, after I fixed the graph coloring regalloc bug that was triggered
by the ARM target, I continue testing and found another bug, this time
on the XCore target. First I thought that it is again specific to my
register allocator, but it seems to be trigerred also by LLVM's
linearscan register allocator.

I don't know if the XCore target is stable enough in LLVM, or may be I
should just safely skip it during testing because it is not mature
yet. Anyway, I report it here - may be it is of some interest.

The crash happens in LiveIntervalsAnalysis, inside the spilling
function. From what I observe, I'd say it is related to
rematerializable intervals.

The assertion says:
/opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142:
llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int):
Assertion `I != r2iMap_.end() && "Interval does not exist for
register"' failed.

I attach the BC file generated by bugpoint, so that you can reproduce it.

The command-line I use is:
llc --regalloc=linearscan --march=xcore -f bugpoint-reduced-simplified.bc

Any ideas about the reasons of this bug?

Thanks,
  -Roman

It looks like it is trying to rematerialize a load from fixed stack slot (LDWSP instruction). This has an implicit use of the SP register which is non allocatable.

rewriteInstructionsForSpills calls getReMatImplicitUse which returns the SP register. This is then followed by a call to getInterval for this register which fails. The attached patch causes getReMatImplicitUse to ignore non allocatable physical registers, which fixes the issue for me. Does this look OK?

bug.patch (613 Bytes)

Roman Levenstein wrote:

Hi again,

Now, after I fixed the graph coloring regalloc bug that was triggered
by the ARM target, I continue testing and found another bug, this time
on the XCore target. First I thought that it is again specific to my
register allocator, but it seems to be trigerred also by LLVM's
linearscan register allocator.

I don't know if the XCore target is stable enough in LLVM, or may be I
should just safely skip it during testing because it is not mature
yet. Anyway, I report it here - may be it is of some interest.

The crash happens in LiveIntervalsAnalysis, inside the spilling
function. From what I observe, I'd say it is related to
rematerializable intervals.

The assertion says:
/opt/llvm/include/llvm/CodeGen/LiveIntervalAnalysis.h:142:
llvm::LiveInterval& llvm::LiveIntervals::getInterval(unsigned int):
Assertion `I != r2iMap_.end() && "Interval does not exist for
register"' failed.

I attach the BC file generated by bugpoint, so that you can reproduce it.

The command-line I use is:
llc --regalloc=linearscan --march=xcore -f bugpoint-reduced-simplified.bc

Any ideas about the reasons of this bug?

Thanks,
-Roman

It looks like it is trying to rematerialize a load from fixed stack slot (LDWSP instruction). This has an implicit use of the SP register which is non allocatable.

rewriteInstructionsForSpills calls getReMatImplicitUse which returns the SP register. This is then followed by a call to getInterval for this register which fails. The attached patch causes getReMatImplicitUse to ignore non allocatable physical registers, which fixes the issue for me. Does this look OK?

This patch assumes non allocatable registers are available at any point. I don't think that's a safe. Can you change LDWSP so it doesn't implicitly use sp? Once the frame index object is lowered by PEI, it can be rewritten to explicitly use sp. Would that work?

Evan

Evan Cheng wrote:

Added. You should also be automatically CC'd on anything filed to that component,

-Chris

Chris Lattner wrote:

Hi Richard,

Thanks for working on this! Your patched solved my initial problem,
but introduced another one. Please find attached another BC file that
fails on xcore with the linear scan regalloc.

This is the error message I get
eliminateFrameIndex Frame size too big: -3
0 llc 0x08affd1e
1 libc.so.6 0xb7d35a01 abort + 257
2 llc 0x081a0972
llvm::XCoreRegisterInfo::eliminateFrameIndex(llvm::ilist_iterator<llvm::MachineInstr>,
int, llvm::RegScavenger*) const + 1570
Aborted

Could you check what is still wrong?

-Roman

Queens.c.bc (7.77 KB)

Roman Levenstein wrote:

Hi Richard,

Thanks for working on this! Your patched solved my initial problem,
but introduced another one. Please find attached another BC file that
fails on xcore with the linear scan regalloc.

This is the error message I get
eliminateFrameIndex Frame size too big: -3
0 llc 0x08affd1e
1 libc.so.6 0xb7d35a01 abort + 257
2 llc 0x081a0972
llvm::XCoreRegisterInfo::eliminateFrameIndex(llvm::ilist_iterator<llvm::MachineInstr>,
int, llvm::RegScavenger*) const + 1570
Aborted

Could you check what is still wrong?

-Roman

I had a fix for this in my local branch which I hadn't got around to commiting. This should be fixed in 62258.

http://llvm.org/viewvc/llvm-project?rev=62258&view=rev

Hi Richard,