search for: mcinstfrag

Hello and happy 2013, Would anyone object to renaming MCInstFragment to MCRelaxableFragment? I believe the latter expresses this class's purpose much more clearly and avoids the confusion with MCDataFragments which also contains instructions. Eli

I guess that is OK, but wouldn't it be better to also rename MCDataFragments then? On 2 January 2013 12:25, Eli Bendersky <eliben at google.com> wrote: > Hello and happy 2013, > > Would anyone object to renaming MCInstFragment to MCRelaxableFragment? > I believe the latter expresses this class's purpose much more clearly > and avoids the confusion with MCDataFragments which also contains > instructions. > > Eli > _______________________________________________ > LLVM Developers mailing list &...

On Thu, Jan 3, 2013 at 11:31 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I guess that is OK, but wouldn't it be better to also rename > MCDataFragments then? > I don't know what a more suitable name would be. Any ideas? Eli

> I don't know what a more suitable name would be. Any ideas? I initially thought MCRelaxedFragment would go well with MCRelaxableFragment, since a MCRelaxableFragment is merged into a MCRelaxedFragment once we are done relaxing it. The problem is that both names are really similar. > Eli Cheers, Rafael

...case 4: OW->Write32(uint32_t(it.getValue())); break; case 8: OW->Write64(uint64_t(it.getValue())); break; } } Note: ObjectWriter has a set of endian correcting routines as use above. The output routines like the snippet above would be in lib/MC/MCAssembler.cpp There is an MCInstFragment, but it doesn't seem to be used. All text and data seem to go through MCDataFragment. The offset/size container would be filled at the lib/Taget/<your target>/MCTargetDesc level. In <your targetMCCODEEmitter.cpp for at least text. Some other source file for data. It would be nice...

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

...: { - 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 &IF = cast<MCInstFragment>(F); + const MCInstFragment &IF = cast<MCInstFragment>(F); OW->WriteBytes(StringRef(IF.getCode().begin(), IF.getCode().size())); break; } case MCFragment::FT_LEB: { - MCLEBFragment &LF = cast<MCLEBFragment>(F); +...

...lue())); break; > case 8: OW->Write64(uint64_t(it.getValue())); break; > } > } > > Note: ObjectWriter has a set of endian correcting routines as use above. > > The output routines like the snippet above would be in lib/MC/MCAssembler.cpp > > There is an MCInstFragment, but it doesn't seem to be used. All text and data > seem to go through MCDataFragment. > > The offset/size container would be filled at the > lib/Taget/<your target>/MCTargetDesc level. In <your targetMCCODEEmitter.cpp > for at least text. Some other source file for...

...())); break; > case 8: OW->Write64(uint64_t(it.getValue())); break; > } > } > > Note: ObjectWriter has a set of endian correcting routines as use above. > > The output routines like the snippet above would be in lib/MC/MCAssembler.cpp > > There is an MCInstFragment, but it doesn't seem to be used. All text and data > seem to go through MCDataFragment. > > The offset/size container would be filled at the > lib/Taget/<your target>/MCTargetDesc level. In <your targetMCCODEEmitter.cpp > for at least text. Some other source file...

...: OW->Write64(uint64_t(it.getValue())); break; >> } >> } >> >> Note: ObjectWriter has a set of endian correcting routines as use above. >> >> The output routines like the snippet above would be in lib/MC/MCAssembler.cpp >> >> There is an MCInstFragment, but it doesn't seem to be used. All text and data >> seem to go through MCDataFragment. >> >> The offset/size container would be filled at the >> lib/Taget/<your target>/MCTargetDesc level. In <your targetMCCODEEmitter.cpp >> for at least text. Some...

...for (unsigned i = 0, e = Instruction.getNumOperands(); i != e; ++i) > + if (Instruction.getOperand(i).isExpr()) > + VisitSymbols(Instruction.getOperand(i).getExpr()); > + > + getSectionData()->setHasInstructions(true); > + > + // FIXME: Who owns this memory? > + MCInstFragment *Fragment = > + new MCInstFragment(Instruction, getSectionData()); > + > + { > + raw_svector_ostream VecOS(Fragment->getCode()); > + > + getAssembler().getEmitter().EncodeInstruction(Instruction, VecOS, Fragment->getFixups()); > + > + // VecOS's de...

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