search for: mcfillfragments

...object where the float is parsed into exponent, mantissa and stored in an integer part is stored in a heap allocated array, then these are emitted into MCDataFragments where again more heap allocated data, the float appears to be stored in SmallVectorImpl<char>. On top of this I see a lot of MCFillFragments added because of long double padding. All up the code I'm compiling ends up with 276 million MCFragments, which just take a super long time in each phase of compiling (loading from bitcode, emitting, layout and writing). With a peak working set of 30 gigabytes each float is taking around 108...

Moving to LLVM dev to discuss the possibility of extending the cast infrastructure to handle this. On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: > On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >> TypeLoc casting looks bogus. >> >> TypeLoc derived types return true from classof when the dynamic type >>

On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: > Moving to LLVM dev to discuss the possibility of extending the cast > infrastructure to handle this. > > On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: >> On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> TypeLoc

While trying to compile an existing codebase which uses handwritten assembly with LLVM, I ran into an issue around using backward references in assembly absolute expressions. A simple example can be the following snippet: _foo: .fill 0x100 _bar: .fill _bar - _foo _baz: .fill 0x100 While gas compiles this snippet without any errors, the integrated assembler throws an error: expected

...at is parsed into exponent, mantissa and stored in an integer > part is stored in a heap allocated array, then these are emitted into > MCDataFragments where again more heap allocated data, the float appears to > be stored in SmallVectorImpl<char>. On top of this I see a lot of > MCFillFragments added because of long double padding. > > All up the code I'm compiling ends up with 276 million MCFragments, which > just take a super long time in each phase of compiling (loading from > bitcode, emitting, layout and writing). With a peak working set of 30 > gigabytes each flo...

Hi Michael, Overall patch looks good. I do have a few comments below. My main comment is please try to make the style match that used in the MCMachOStreamer more closely. I intend to refactor more functionality into the base MCObjectStreamer class, and having them use consistent idioms makes this easier; specific instances are included in the comments: -- > diff --git

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer