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

[Dan Gohman]

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.

Dan