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

Christian Sayer Christian.Sayer at dibcom.fr
Mon Feb 9 01:51:40 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,
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.




More information about the llvm-dev mailing list