[LLVMdev] list-td scheduler asserts on targets with implicitly defined registers
Evan Cheng
echeng at apple.com
Fri Feb 6 09:02:39 PST 2009
The best fix is to teach this scheduler how to deal with these
dependencies. :-)
If you just want a check, I think it's easier to just check register
class's copy cost. -1 means it's extremely expensive to copy registers
in the particular register class.
Evan
On Feb 6, 2009, at 2:22 AM, Christian Sayer wrote:
> 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.
> <
> patch2_X86eflagsAllocatable
> .patch
> >
> <
> patch1_physregAlloc
> .patch>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev
mailing list