[llvm-commits] [PATCH] Avoid overflow in scheduling

[Evan Cheng]

On Sep 28, 2009, at 9:45 AM, Dan Gohman wrote:

>
> On Sep 27, 2009, at 9:17 PM, Reid Kleckner wrote:
>>
>> I think the characteristic of this input is that we have 35K BB's in
>> the function, and each line has a guard that creates a basic block
>> edge to a single bailing block.  When it's time to do scheduling,  
>> that
>> manifests as more than SHRT_MAX predecessors, causing the overflow in
>> NumSuccs.
>
> The NumPreds and NumSuccs values are talking about scheduling
> units within a basic block, not basic blocks themselves.  So it sounds
> like you not only have large numbers of BBs, but you also have
> some large individual BBs :-).
>
>>
>> Talking with jyasskin and nlewycky, we think that if LLVM wants the
>> language restriction that there be no more than SHRT_MAX incoming
>> edges to a basic block, that's fine, but the verifier should catch  
>> it,
>> because we run the verifier on our code.  Otherwise, scheduling
>> probably needs to support more predecessors.
>
> I don't think we want a language restriction like this.  I favor  
> changing the
> fields to ints for now.
>
> I think there are some opportunities to make the scheduler use less
> memory that we can pursue instead of trying to get by with short  
> fields.

Alright.

Evan

>
> Dan
>