Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assertion `!empty() && "empty range"' failed. #45499

Closed
JonPsson opened this issue Jun 1, 2020 · 5 comments
Closed

Assertion `!empty() && "empty range"' failed. #45499

JonPsson opened this issue Jun 1, 2020 · 5 comments
Labels
bugzilla Issues migrated from bugzilla llvm:regalloc

Comments

@JonPsson
Copy link
Contributor

JonPsson commented Jun 1, 2020

Bugzilla Link 46154
Resolution FIXED
Resolved on Jun 03, 2020 17:15
Version trunk
OS Linux
Attachments reduced (very small) test case
CC @kparzysz-quic,@JonPsson,@qcolombet,@uweigand

Extended Description

llc -mtriple=s390x-linux-gnu -mcpu=z13 -O3 -pre-RA-sched=list-ilp -systemz-subreg-liveness -stress-sched -terminal-rule tc_notempty_emptyrange.ll -o -

llc: /home/ijonpan/llvm-project/llvm/lib/CodeGen/LiveInterval.cpp:447: bool llvm::LiveRange::overlaps(const llvm::LiveRange&, const llvm::CoalescerPair&, const llvm::SlotIndexes&) const: Assertion `!empty() && "empty range"' failed.

...
#​11 0x000002aa15de122e (anonymous namespace)::RAGreedy::tryAssign

@qcolombet
Copy link
Collaborator

The problematic interval is %4.
Before coalescing it looks like this:
%4 [80r,256r:0) 0@80r weight:0.000000e+00

After coalescing %4 has been promoted from a gpr32 to a gpr128 while merged with the various copy. Yet only the low 32-bit lane is used and the other lanes are empty:
%4 [80r,256r:0) 0@80r L0000000000000007 EMPTY L0000000000000008 [80r,256r:0) 0@80r weight:0.000000e+00

The code looks like this after coalescing:
80B undef %4.subreg_l64:gr128bit = LGHI 0
<...>
256B STC %4.subreg_l32:gr128bit, %2:addr64bit, 19, $noreg :: (store 1 into i8* getelementptr inbounds ([7 x [10 x i8]], [7 x [10 x i8]]* @&#8203;g_222, i64 0, i64 1, i64 9))

I would have expected %4 to define dead refs on 80B instead of keeping the lanes empty. So probably an issue with how we create the subranges when we do rematerialization here.

For the record the reason why the option -terminal-rule is needed is because otherwise %4 gets merged with %3 and the one that gets the dematerialization is %9 which is already a 128-bit value, so we don't create empty lanes when we rematerialize.

@qcolombet
Copy link
Collaborator

So probably an issue with how we create the subranges when we do rematerialization here.

I concur the code that updates the subranges when the definition has a subreg, only cleans up unused and not defined empty lanes but doesn't assign the proper dead def to the one that are unused but defined.

Attaching a tentative patch.

@qcolombet
Copy link
Collaborator

Tentative patch

@qcolombet
Copy link
Collaborator

With the attached patch, %4 looks much more reasonable after coalescing:
%4 [80r,256r:0) 0@80r L0000000000000007 [80r,80d:0) 0@80r L0000000000000008 [80r,256r:0) 0@80r weight:0.000000e+00

@qcolombet
Copy link
Collaborator

Fixed in
https://github.com/llvm/llvm-project.git
eb9ca9d..ccb3c8e master -> master

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla llvm:regalloc
Projects
None yet
Development

No branches or pull requests

2 participants