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

[Evan Cheng]

Looks fine. Please commit. Thanks.

Evan

On Sep 30, 2009, at 11:56 AM, Reid Kleckner wrote:

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