[llvm] r212203 - Don't try to construct debug LexicalScopes hierarchy for functions that do not have top level debug information.

[David Blaikie]

Recommitted with a fix (& doesn't crash on the reproduction given by
Aditya) in r212649. Thanks guys - let me know if you see anything
else!

On Mon, Jul 7, 2014 at 10:20 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Mon, Jul 7, 2014 at 10:07 PM, Duncan P. N. Exon Smith
> <dexonsmith at apple.com> wrote:
>>
>>> On 2014 Jul 7, at 20:22, David Blaikie <dblaikie at gmail.com> wrote:
>>>
>>> On Thu, Jul 3, 2014 at 6:01 PM, Aditya Nandakumar
>>> <aditya_nandakumar at apple.com> wrote:
>>>> Thanks Duncan
>>>> Bug point reduced it from 27MB to about 3.7. I ran it through opt and
>>>> brought it down to 2.4MB and am unable to reduce further. Hopefully this is
>>>> not too big.
>>>
>>> I'll have to take a look, though I'm a bit concerned that a reduced IR
>>> is going to be tricky to actually pinpoint the original source of the
>>> problem as the IR may already contain the bad debug info metadata at
>>> this point... and I won't be able to discover where that was
>>> introduced (by which optimization, etc).
>>>
>>> But I'll take a look, see if I can create something by hand, etc...
>>> and see how I go.
>>>
>>> Thanks,
>>> - David
>>
>> Heh... doesn't sound fun.
>
> One saving grace - I have got code I can enable in the debug info
> verifier that will help me pinpoint the optimization pass that
> introduces the problem. (though reducing LTO input is a bit of a pain,
> but not impossible with a few hints from such investigation)
>
>> FWIW, the source file (27MB) is from pre-LTO
>> optimizations -- i.e., it's the merged bitcode at the beginning of LTO.
>> If you think that would be more helpful than the bugpoint-reduced
>> version, Aditya might still have it around.
>
> Could be handy, if someone wants to put it somewhere I can access it.
> (google drive, for example)