[llvm] r237827 - Add bool to DebugLocDwarfExpression to control emitting comments.
Pete Cooper
peter_cooper at apple.com
Wed May 20 15:56:13 PDT 2015
> On May 20, 2015, at 3:43 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>
>
>> On 2015 May 20, at 13:58, Pete Cooper <peter_cooper at apple.com> wrote:
>>
>>>
>>> On May 20, 2015, at 1:54 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>>
>>>
>>>
>>> On Wed, May 20, 2015 at 1:46 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>>
>>>
>>> On Wed, May 20, 2015 at 1:38 PM, Pete Cooper <peter_cooper at apple.com> wrote:
>>> Looks like there wasn’t worth using anything in the original commit. I’ll revert it shortly.
>>>
>>> What do you think of this one?
>>>
>>> Looks plausible, but looping in Duncan because I assume his r235229 (April 17) was the cause of this?
>>>
>>> Is it possible we could avoid the extra stream/buffer entirely and just stream them out from collectVariableInfo? I assume this would fragment the debug info data, though (since we'd be switching sections back & forth) - I'm not sure if that's a bad/problematic thing...
>>>
>>> I guess that's the 3rd fixme? Perhaps worth considering together.
>>>
>>> Also I'm a bit confused about this design, now that I look at it a bit more...
>>>
>>> Seems a bit awkward and the original commit doesn't mention the savings (or maybe it does) - mentions 10-15% of memory allocation coming from that function, not sure how much was avoided by this change.
>> Sorry, should have mentioned numbers. This is a drop in the ocean (10000 allocations generating 300KB of data), and pretty much entirely unrelated to Duncan’s recent email. Same files, but not on the path he was looking at.
>>
>> Seemed like an easy fix for the sake of 10000 allocations saved which is why I did it. Had it been fewer I doubt i’d have tried TBH.
>>>
>>> Rambling: This doesn't seem like a stream any more than the original data structure, it's the "array of structs to struct of arrays" transformation... I would imagine we could make that a bit of a nicer abstraction than what's here, but maybe I'm missing something. Seems rather awkward having to pull out the components (comments, etc) by lookup of Entry rather than getting a whole Entry. Having the iterator over the loc lists produce whole objects that reference the various vector contents would be nice (proxy object - doesn't add allocation overhead, but gives a unified view of the list in the same pivot as the code before this commit, etc)
>> Yeah, i’m open to improving the structure here. Let me take a look at collectVariableInfo as you pointed out. Perhaps there’s a much nicer solution if we start from there, or even just emit the comments directly.
>>
>> Pete
>
> IMO, any next steps should just emit this stuff directly to the
> output section, rather than holding onto them to emit later.
> It's not clear to me how hard that is, but it would be a nice
> cleanup.
Sounds good. I’ll take a look and see what needs to be done for this.
BTW, the original commit here was reverted in r237849 with the new patch applied in r237851.
Cheers,
Pete
>
More information about the llvm-commits
mailing list