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

Christian Sayer
2009-02-09T09:51:40Z

> 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,
I am not sure what you mean by "if you just want a check" - I was
trying to point out that for example the following very simple testcase makes
llc -march=x86 -pre-RA-sched=list-td crash :

define i32 @cctest(i32 %a, i32 %b) nounwind readnone {
entry:
        %not. = icmp sge i32 %a, %b             ; <i1> [#uses=1]
        %.0 = zext i1 %not. to i32              ; <i32> [#uses=1]
        ret i32 %.0
}

The assert() which triggers has been introduced since llvm 2.4.
So I assume that (at least for the time being) the assert condition has to be
made less restrictive. I also assume that this is ok because the dependency is
rather a 'flag' dependency than one to be resolved by the scheduler.
So the question would be if these assumptions are correct and if it is safe to
exclude implicitly defined physreg dependencies from the assert the way I
proposed. Furthermore, I was thinking that the exception should not apply on
allocatable registers, since the scheduler propably really cannot handle such.
When I realized that X86 EFLAGS is actually allocatable, I was wondering why,
but there is certainly a reason...

Best 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.