search for: mcfillfrag

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

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

...mp;DF = cast<MCDataFragment>(F); + const MCDataFragment &DF = cast<MCDataFragment>(F); assert(FragmentSize == DF.getContents().size() && "Invalid size!"); OW->WriteBytes(DF.getContents().str()); break; } case MCFragment::FT_Fill: { - MCFillFragment &FF = cast<MCFillFragment>(F); + const MCFillFragment &FF = cast<MCFillFragment>(F); assert(FF.getValueSize() && "Invalid virtual align in concrete fragment!"); @@ -456,19 +456,19 @@ } case MCFragment::FT_Inst: { - MCInstFragment &amp...

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

...if given, and the section takes ownership of it (this is an idiom we use pervasively for LLVM IR, its very succinct/useful once you get used to it). AddFragment() should be eliminated here and throughout the file. > + > + // FIXME: Who owns this memory? > + SymbolData->Fragment = new MCFillFragment( > + 0, 0, Size, SectionData > + ); > + > + AddFragment(SymbolData->Fragment); > } > > // MCStreamer interface > > void WinCOFFStreamer::EmitLabel(MCSymbol *Symbol) { > + // FIXME: Who owns this memory? > + MCDataFragment *Fragment = new MCDataFragm...

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