search for: createasmprint

...r pass to the end of X86PassConfig::addPreEmitPass() and it will currently be the last thing to run before the asm printer, but I don’t know if thats a guarantee or not. In theory anyone could add something after the call to preEmitPass and before this code FunctionPass *Printer = getTarget().createAsmPrinter(*this, *AsmStreamer); PM.add(Printer); but if they do you can shout loudly :) Thanks, Pete > > -Andy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/li...

...packages them into a separate function. [As a side note, I don't understand how the two AsmPrinters (one for the module pass manager, one for the function pass manager) end up pointing to the same MCContext as LLVMTargetMachine::addPassesToEmitFile() creates a new MCContext to pass to Target::createAsmPrinter. Insights welcome. :)] Perhaps there is a better way of doing this that's officially supported. Is this model of function processing supported at all? If not, has anyone thought about how we might support it? I think this is a model that is not all that uncommon so I would hope we could...

Hi, I would like to execute a MachineFunctionPass after all other passes which modify the machine code. In other words, if we call llc to generate assembly file, that pass should run right before the "Assembly Printer" pass. Is there any official way to enforce this ? Best regards, Sebastien

...parate function. > > [As a side note, I don't understand how the two AsmPrinters (one for the > module pass manager, one for the function pass manager) end up pointing > to the same MCContext as LLVMTargetMachine::addPassesToEmitFile() > creates a new MCContext to pass to Target::createAsmPrinter. Insights > welcome. :)] > > Perhaps there is a better way of doing this that's officially supported. > Is this model of function processing supported at all? If not, has > anyone thought about how we might support it? I think this is a model > that is not all that uncom...

...f the tools that call createMCAsmInfo() link multiple object files (e.g. llvm-rtdyld, and llvm-dwp) and may therefore need to implement the ABI inter-linking rules. Looking beyond enabling IAS for N64 towards fixing N32 support for IAS, the same requirements would apply to createMCSubtargetInfo(), createAsmPrinter() (because the Mips, PowerPC, AMDGPU, and WebAssembly targets call createMCSubtargetInfo() in their implementations), createMCCodeEmitter(), and createMCAsmBackend(). IRLinker would also need to handle the incompatibility between the O32 and N32/N64 ABI's IR-level since frontends can generate...

On 24 June 2016 at 06:02, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > Hi, > > Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in

Hi, Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in the triple and that's the only information MipsMCAsmInfo has. This would be fine if it N32 was

...MCContext &Ctx, MCStreamer &Out, + const MCAsmInfo &MAI) const { if (!AsmParserCtorFn) return 0; - return AsmParserCtorFn(*this, Parser); + return AsmParserCtorFn(*this, Triple, SM, Ctx, Out, MAI); } /// createAsmPrinter - Create a target specific assembly printer pass. This @@ -667,8 +675,10 @@ namespace llvm { } private: - static TargetAsmParser *Allocator(const Target &T, MCAsmParser &P) { - return new AsmParserImpl(T, P); + static AsmParser *Allocator(const Target &T, const s...