[llvm-dev] Performance of large llvm::ConstantDataArrays
Rafael Avila de Espindola via llvm-dev
llvm-dev at lists.llvm.org
Thu Sep 14 09:56:04 PDT 2017
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
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
>> 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
>> 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!
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev