search for: mcfragment

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

...Out << "\n "; writeOperand(i.getCaseValue(), true); Index: lib/MC/MCAssembler.cpp =================================================================== --- lib/MC/MCAssembler.cpp (revision 168949) +++ lib/MC/MCAssembler.cpp (working copy) @@ -336,7 +336,7 @@ } case MCFragment::FT_Org: { - MCOrgFragment &OF = cast<MCOrgFragment>(F); + const MCOrgFragment &OF = cast<MCOrgFragment>(F); int64_t TargetLocation; if (!OF.getOffset().EvaluateAsAbsolute(TargetLocation, Layout)) report_fatal_error("expected assembly-time absolute ex...

...unnammed "virtual" symbol can be used when there is no explicit label defined. > > What do you mean by fragment? Can you give me an analogy with what the syntax looks like in a .s file, I'm not sure exactly what you mean here. > > I use the term fragment to refer to the MCFragment class and its derivatives. I understand that to mean any entity representing data in the final linked and loaded form. (something with an address) Ok, MCFragment should definitely be formed behind the MCStreamer implementation. The .s printing implementation of MCStreamer, for example, has no use...

...Marking "suspicious" places while encoding, i.e. hotspots that may cause a performance penalty, during the encoding. 2. Computing the actual number (zero or greater) of required nops in order to avoid a performance penalty. In order to achieve that, I am introducing a new kind of MCFragment named MCPerfNopFragment. It will be the connecting link between the two phases: 1. During encoding, the object streamer (MCObjectStreamer) will query the backend for the need of a MCPerfNopFragment before every encoded instruction. If required, a MCPerfNopFragment will be created and inserted...

...I reckon that in most cases MC clients aren't going to be copying large amounts of unowned data, they're most likely going to be creating that data. So perhaps the implementation should reflect that somehow. Specifically what I had in mind was that you could add some other derived class of MCFragment that would store a StringRef (or maybe a vector of StringRefs if that proves useful), and that would be unrelated to MCDataFragment. WDYT? Thanks, -- Peter

...ed 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 bytes! Is there a more efficient way to do this? Or is there any plan in the works to handle global data mor...

...med "virtual" symbol can be used when there is no explicit label > defined. > > What do you mean by fragment? Can you give me an analogy with what the > syntax looks like in a .s file, I'm not sure exactly what you mean here. > I use the term fragment to refer to the MCFragment class and its derivatives. I understand that to mean any entity representing data in the final linked and loaded form. (something with an address) > Section assignment should be the responsiblity of the object imlementing > the > > MCStreamer interface, with the caller givin the abilit...

On Mon, Feb 29, 2016 at 3:36 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi David, > > The way I imagined that we might want to extend the MCStreamer API (this > was motivated by DIEData) is by allowing clients to move bytes and fixups > into the MC layer. > > This is the sort of API that I was imagining: > > void

...ol can be used when there is no explicit label >> defined. >> >> What do you mean by fragment? Can you give me an analogy with what the >> syntax looks like in a .s file, I'm not sure exactly what you mean here. > > >> I use the term fragment to refer to the MCFragment class and > its derivatives. I understand that to mean any entity representing data in > the final linked and loaded form. (something with an address) > > > Ok, MCFragment should definitely be formed behind the MCStreamer > implementation. The .s printing implementation of MCStre...

On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > This is a brain-dump of my thoughts on the MCStreamer interface after several > days of digging around trying to get a COFF writer working. Great! Something that is worth pointing out is that the MCStreamer API is intended to directly reflect what is happening in .s files. We basically want one MCStreamer callback to correspond to one

...or the same reasons, the nops insertion process also cannot occur until after the encoding phase. Regarding splitting blocks of code, that is essentially what I’m proposing, but at MC level (since this is the level I’m operating in). When needed, a MCPerfNopFragment will be a separator between two MCFragments that contain code (e.g. MCDataFragments). However, a MCPerfNopFragment is not a MCAlignFragment and a block that follows a MCDataFragments will not (necessarily) be aligned as it could be wasteful in terms of code size. Consider the example I provided. Aligning the fragment after the nops to 16B w...

...ragment *DF, + const MCAsmLayout &Layout) const { + return false; + } + + virtual void processFixupValue(const MCAssembler &Asm, + const MCAsmLayout &Layout, + const MCFixup &Fixup, const MCFragment *DF, + MCValue &Target, uint64_t &Value, + bool &IsResolved) { + AArch64AsmBackend::processFixupValue(Asm, Layout, Fixup, DF, Target, Value, + IsResolved); + if ((uint32_t)Fixup...

...Marking "suspicious" places while encoding, i.e. hotspots that may cause a performance penalty, during the encoding. 2. Computing the actual number (zero or greater) of required nops in order to avoid a performance penalty. In order to achieve that, I am introducing a new kind of MCFragment named MCPerfNopFragment. It will be the connecting link between the two phases: 1. During encoding, the object streamer (MCObjectStreamer) will query the backend for the need of a MCPerfNopFragment before every encoded instruction. If required, a MCPerfNopFragment will be created and inserted...

...MCSymbolData *SymbolData); These aren't used, can you just remove them and add them when they actually are needed? > + MCSectionData *getSectionData(MCSection const *Section = 0); > + MCSymbolData *getSymbolData(MCSymbol const *Symbol); > + > + void AddFragment(MCFragment *Fragment); This function isn't necessary, fragments see below. > + void VisitSymbols(MCExpr const *Expr); > + > + void AddCommonSymbol(MCSymbol *Symbol, uint64_t Size, > + unsigned ByteAlignment, bool External); > + > // MCStreamer interface >...

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

This is a brain-dump of my thoughts on the MCStreamer interface after several days of digging around trying to get a COFF writer working. All fragments should be associated with a symbol. For assembler components, a unnammed "virtual" symbol can be used when there is no explicit label defined. Section assignment should be the responsiblity of the object imlementing the MCStreamer

...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 bytes! > > Is there a more efficient way to do this? Or is there any plan in the > wo...

Right now MC is optimized for emitting assembly, but as Rafael pointed out to me over IRC the optimized path should be emitting object files. This WIP patch moves MCSymbolData into MCSymbol.h and makes it a field inside MCSymbol. This eliminates a pointer from MCSymbolData back to MCSymbol, the DenseMap<const MCSymbol *, MCSymbolData *> in MCAssembler, and converts the iplist in