[llvm-dev] Performance of large llvm::ConstantDataArrays

[Rafael Avila de Espindola via llvm-dev]

MC should not be creating new fragments when outputting non
instructions, it should just append to the current one.

See MCObjectStreamer::getOrCreateDataFragment, something around it is
not working.

Cheers,
Rafael


Chris Lovett via llvm-dev <llvm-dev at lists.llvm.org> writes:

> Well I have a great test case if someone wants to help show me where/how to
> fix this in MC.
>
> On Mon, Sep 11, 2017 at 8:24 PM, Chris Lattner <clattner at nondot.org> wrote:
>
>> On Sep 10, 2017, at 1:34 AM, Sean Silva <chisophugis at gmail.com> wrote:
>>
>>
>> IMO, there is a relatively easy solution for this.  Introduce a new
>>> subclass of ConstantData which represents a blob of data that gets emitted
>>> to the .o file, stored in a reasonable native format.  I think it would be
>>> fine to limit this to only representing arrays of primitive types (e.g.
>>> array of float, array of bytes, etc) since this keeps the API to the type
>>> simple (the type models an array, so it should have array element members
>>> only), and things that want to get the elements of the array out can have
>>> them returned as ConstantInt’s (or whatever).  I’d name this something like
>>> “ConstantArrayBlob”.
>>>
>>
>>
>> What's the relationship between ConstantDataArray and ConstantArray?
>>
>>
>> Ah, it looks like ConstantDataArray is exactly what I was advocating for.
>> Does Clang generate it from an array of doubles?  Maybe that is all that is
>> missing.
>>
>> densely packed data, instead of as Value*'s." so I assumed that it was a
>> dense representation and it seemed reasonable that an i8 typed one of them
>> would basically operate as a "ConstantArrayBlob". (but I guess if MC still
>> creates one fragment per element that will still be a memory hog regardless
>> of the IR's representation)
>>
>>
>> Yeah, MC should totally be fixed.  That’s crazy!
>>
>> -Chris
>>
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev