[llvm-dev] Performance of large llvm::ConstantDataArrays (original) (raw)

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 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

More information about the llvm-dev mailing list