[LLVMdev] list-td scheduler asserts on targets with implicitly defined registers

Christian Sayer Christian.Sayer at dibcom.fr
Fri Feb 6 02:22:01 PST 2009


Hi,

I just switched to the 2.5 release branch and noticed that llc runs into the following assert in ScheduleDAGList::ScheduleNodeTopDown() using our custom backend:

    assert(!I->isAssignedRegDep() &&
           "The list-td scheduler doesn't yet support physreg dependencies!");

It turns out that the register dependency concerns the condition code register which is modeled as an implicitly defined register in the backend (the same happens for e.g. for X86 when explicitly giving the -pre-RA-sched=list-td option to llc).

My assumption is that the assert should exclude non-allocatable, implicitly defined registers, which is checked in the attatched patch1.
This works fine for me, however on X86 the EFLAGS register is not marked non-allocatable (patch2).
Is this intentional? Our backend handles condition codes pretty much like X86 and I remember I didn't get it to work without defining the allocation_order_end() function in RegisterInfo.td
Anyway, I have no idea if this solution is ok for the general case, maybe the implicit defs information should rather be put into the SDeps when they are created?

Regards,
Christian

--







please ignore:

CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch2_X86eflagsAllocatable.patch
Type: application/octet-stream
Size: 649 bytes
Desc: patch2_X86eflagsAllocatable.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090206/946c9800/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch1_physregAlloc.patch
Type: application/octet-stream
Size: 1641 bytes
Desc: patch1_physregAlloc.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090206/946c9800/attachment-0001.obj>


More information about the llvm-dev mailing list