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

[Evan Cheng]

On Feb 9, 2009, at 1:51 AM, Christian Sayer wrote:

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

I was saying that instead of checking whether the physical register is  
allocatable, you might want to check the CopyCost of the register  
class (assuming it belongs to only one) is a negative value. That  
indicates it's extremely expensive to copy the physical register.

I think marking EFLAGS non-allocatable is fine. But I don't think it's  
the right fix. For example, ESP is not allocatable but you can insert  
a pair of copies (ESP to vreg and then vreg to ESP) to handle the  
dependency.

Evan
>
>
> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev