search for: targetspecif

...could do that, but it is MCAsmStreamer that is printing the final value of most symbols together with their EOL. So, unless I start using rewinding streams or print the symbols myself, I can't see other way. I could add a call-back there, instead of calling it Relocation->print(OS), call it TargetSpecific->prePrint(OS) and posPrint(OS), just before and after printing the value. Or even make them simple methods in ARM/MCAsmInfo, but then it'd be more than just "info" in there. Or have a reference on MAI to the target's asm printer, that might be the easiest, non-intrusive chang...

...m = 1, Exactly. > Those definitions are used in codegen, and and TableGen somehow passes the > instruction format information to X86GenInstInfo.inc -- specifically, it > encodes it in the TSFlags field of the TargetInstrDescriptor class. Yup, the TSFlags field is defined to hold TargetSpecific flags of whatever sort you want. Just the thing for holding information about how to print. > So the question is: how the information about format should be specified > in .td files? I've tried this: > But the values of the TSFlags field for did not change. This one is definitely...

Hello, I'm trying to write assembler code writer, and of course, have new questions. I'd like the structure my implementation like this: if (/*binary instruction*/) { // print destination O << " = "; // print first operand O << opcode; // print second operand. } if (/* unary instruction */ ) { .... } if (/*control instruction*/) { ....

Is there a way to handle this entirely in the ARM AsmPrinter bits? Adding pieces to the generic MC stuff feels a bit like overkill at first impression. On a minor note: You probably want dyn_cast<> instead of cast<> so you can do something like: if (const MCSectionELF* SectionELF = dyn_cast<MCSectionELF>(Section)) { // ... } -Jim On Jun 16, 2010, at 3:44 PM, Evan Cheng

Sorry, I have been very behind on patch reviews. Bob and Jim, do you have any opinions about this? Evan On Jun 2, 2010, at 5:18 AM, Renato Golin wrote: > Hi, > > Is there any interest in this patch? Is there any better way of doing this (that will be accepted mainstream)? > > I noticed my cast check was wrong (LLVM cast asserts, rather than return a null pointer). Also,