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

[Reid Kleckner]

Ping?

Reid

On Mon, Sep 28, 2009 at 8:29 PM, Reid Kleckner <rnk at mit.edu> wrote:
> Here's an updated patch.  I also switched the numbers to be unsigned
> since they should never be negative.
>
> Reid
>
> On Mon, Sep 28, 2009 at 4:26 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>>
>> 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
>>>
>>
>>
>