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

[Chris Lovett via llvm-dev]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170913/c3870608/attachment.html>