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

[Will Dietz]

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