[PATCH] TypeFinder: use iterative algorithm to avoid stack overflow.

[Rafael Espíndola]

LGTM. Sorry for the long delay.

On 15 October 2013 15:25, Will Dietz <w at wdtz.org> wrote:
> Ping? :)
>
> Thanks!
>
> ~Will
>
> On Fri, Oct 11, 2013 at 2:47 AM, Will Dietz <w at wdtz.org> wrote:
>> To elaborate:
>>
>> Making a quick survey of bitcode files I have on hand suggests
>> types never nest more than ~250 deep, usually much less.
>>
>> At these levels, the difference in stack usage of llvm-dis before
>> and after is 12KB vs 27KB.  This was measured with
>> the attached synthetic "types.small.bc" file (200 deep)
>> by using "ulimit -s" to find the small stack size that would run
>> successfully with and without this patch.
>>
>> Scaling up the type nesting depth to admittedly
>> unrealistic depths (60,000) causes stack usage
>> to go over 4MB before this patch while still
>> running with 12KB afterwards.  This was measured
>> using the attached (xz-compressed) types.bc file.
>>
>> Importantly, AFAICT there is no performance impact with this change.
>>
>> In short, while the stack usage issue is unlikely to be an issue
>> for most users it seems like a strict improvement over
>> the current state and can be an important change in
>> environments with very limited stack or with particularly
>> worst-case scenario bitcode files and normal stack sizes.
>>
>> Finally, I've also attached an updated patch that fixes
>> a minor whitespace issue that somehow managed
>> to sneak into the original.
>>
>> Thank you for your time :).
>>
>> ~Will
>>
>> On Thu, Oct 10, 2013 at 5:58 PM, Will Dietz <w at wdtz.org> wrote:
>>> See attached.
>>>
>>> Without this change, TypeFinder can use a large amount of stack space
>>> when processing modules with deeply nested type references.
>>>
>>> Okay to commit?
>>>
>>> ~Will
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits