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

[Dan Gohman]

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.

The assertion changes potential miscompilations to compiler aborts.  It
triggers more often than strictly necessary; the above testcase would  
not
have been miscompiled, but slightly more complicated ones would be.

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


The basic situation is A defines a value in register R that's read by  
B, and C
clobbers R.  Here, C can be scheduled before A and B, or after A and  
B, but
not in between. This can happen with allocatable registers as well as
non-allocatable ones.  It also can't easily be modeled in a simple
dependency graph.

CodeGen used to handle this by always using "Flag" dependencies, which
effectively require that nothing be scheduled between A and B.  This is
simple, and it worked with all the schedulers, however, it's over- 
restrictive.

A while ago, the list-burr scheduler was enhanced to support physical
register dependencies, and some things were changed to make use of
this, instead of using the Flag mechanism. Eventually, more things  
will be
converted over.

Patches to add physical register dependency tracking to the other
schedulers would be welcome.

Dan