[llvm-commits] [PATCH] Avoid overflow in scheduling
evan.cheng at apple.com
Mon Sep 28 13:26:50 PDT 2009
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,
>> manifests as more than SHRT_MAX predecessors, causing the overflow in
> 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
>> 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
More information about the llvm-commits