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

[Will Dietz]

No worries, thanks for the review! :)

Committed as r192770.

~Will

On Tue, Oct 15, 2013 at 10:25 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> 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