search for: createmcasmbackend

...to convert these raw pointers (and worse: references!) to unique_ptrs (apologies to people whose backbends I've broken), but I hit a big blocker when I get to Target in "llvm/Support/TargetRegistry.h". Target vends MC objects by calling registered ctor functions. E.g.: MCAsmBackend *createMCAsmBackend(const MCRegisterInfo &MRI, StringRef TheTriple, StringRef CPU, const MCTargetOptions &Options) const { if (!MCAsmBackendCtorFn) return nullptr; return MCAsmBackendCtorFn(*this, MRI, Triple(TheTriple), CPU, Options); }...

...o many arguments to function call, expected 3, have 4 MCOptions); ^~~~~~~~~ /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:401:3: note: 'createMCAsmBackend' declared here MCAsmBackend *createMCAsmBackend(const MCSubtargetInfo &STI, ^ 2 errors generated. Apparently, this has been broken for several months. I think I can fix this particular instance, but I was wondering whether anybody cares about this tool? -- Davide "There are no...

...o function call, expected 3, have 4 > MCOptions); > ^~~~~~~~~ > /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:401:3: > note: 'createMCAsmBackend' declared here > MCAsmBackend *createMCAsmBackend(const MCSubtargetInfo &STI, > ^ > 2 errors generated. > > Apparently, this has been broken for several months. I think I can fix > this particular instance, but I was wondering whether anybody cares > about this tool?...

...expected 3, have 4 >> MCOptions); >> ^~~~~~~~~ >> /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/include/llvm/Support/TargetRegistry.h:401:3: >> note: 'createMCAsmBackend' declared here >> MCAsmBackend *createMCAsmBackend(const MCSubtargetInfo &STI, >> ^ >> 2 errors generated. >> >> Apparently, this has been broken for several months. I think I can fix >> this particular instance, but I was wondering whether anybody care...

...riter(). One of your commits on Monday (r227102) seems to make this a lot easier than it was looking last week when Vladimir and I were discussing this internally (I've been off sick so I only saw your commit last night). I haven't had chance to try this but I'm currently thinking that createMCAsmBackend() should have an LLVMTargetMachine* argument. The Mips-specific versions of this function can then get the ABI name from there and pass it down to createMipsELFObjectWriter(). From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eric Christopher Sent: 28 Januar...

...riter(). One of your commits on Monday (r227102) seems to make this a lot easier than it was looking last week when Vladimir and I were discussing this internally (I've been off sick so I only saw your commit last night). I haven't had chance to try this but I'm currently thinking that createMCAsmBackend() should have an LLVMTargetMachine* argument. The Mips-specific versions of this function can then get the ABI name from there and pass it down to createMipsELFObjectWriter(). From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eric Christopher Sent: 28 Januar...

..._unique<buffer_ostream>(Out->os()); OS = BOS.get(); } This also seems to do OK. Now I would think I can finally get around to making the code emitter and the MCStreamer: MCCodeEmitter *CE = TheTarget->createMCCodeEmitter(*MCII, *MRI, Ctx); MCAsmBackend *MAB = TheTarget->createMCAsmBackend(*MRI, TripleName, MCPU); MCStreamer *Str = TheTarget->createMCObjectStreamer(TheTriple, Ctx, *MAB, *OS, CE, *STI, true, false); So, like, wow, I would think I should be good to go here! I should be able to just use functions like: Str->EmitInstruction(); Str->EmitLabel(); The...

...relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. * Call createMCInstrInfo * Call createMCSubtargetInfo(Triple, ...) * If emitting assembly: * Call createMCInstPrinter(Triple, ...) * If emitting encodings: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * Call createMCAsmStreamer() * If emitting objects: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * createMCObjectStreamer() * This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsA...

...relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. * Call createMCInstrInfo * Call createMCSubtargetInfo(Triple, ...) * If emitting assembly: * Call createMCInstPrinter(Triple, ...) * If emitting encodings: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * Call createMCAsmStreamer() * If emitting objects: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * createMCObjectStreamer() * This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsA...

Hi all, we have several features in Mips that are dependent on target abi. A recent commit(r224492) introduced a new -target-abi option to TargetOptions struct that provides access to abi string. This info is stored in MCSubtarget class(ARMSubratget in this case) and distributed to other libraries. Unfortunately, for Mips we need this info in other classes that don't have access to MCSubtarget

...relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. * Call createMCInstrInfo * Call createMCSubtargetInfo(Triple, ...) * If emitting assembly: * Call createMCInstPrinter(Triple, ...) * If emitting encodings: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * Call createMCAsmStreamer() * If emitting objects: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * createMCObjectStreamer() * This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsA...

...s. 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 different IR for different calling conventions. Other targets handle this incompatibility by having different triples. I think N32 and N64 are compatible at the LLVM...

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

...ou mean..." responses in LLVM tools for unrecognised options. This functionality was previously only available in the CommandLine library which isn't used by tools like Clang or Swift. [r321877](http://reviews.llvm.org/rL321877). * An MCSubtargetInfo reference is now pased through target::createMCAsmBackend. This allows subtarget feature support to be easily queried, with a number of follow-on cleanups suggested in the commit message. The suggested ARMAsmBackend cleanup has already been implemented and committed.[r321692](http://reviews.llvm.org/rL321692), [r321707](http://reviews.llvm.org/rL321707)....

...relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. * Call createMCInstrInfo * Call createMCSubtargetInfo(Triple, ...) * If emitting assembly: * Call createMCInstPrinter(Triple, ...) * If emitting encodings: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * Call createMCAsmStreamer() * If emitting objects: * Call createMCCodeEmitter() * Call createMCAsmBackend(..., Triple, ...) * createMCObjectStreamer() * This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsA...

...sonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. · createMCInstrInfo() · createMCInstPrinter() · createMCCodeEmitter() · createMCAsmBackend() · If emitting assembly, createMCAsmStreamer() · if emitting object, createMCObjectStreamer() o This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs Triple:...

...sonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. • createMCInstrInfo() • createMCInstPrinter() • createMCCodeEmitter() • createMCAsmBackend() • If emitting assembly, createMCAsmStreamer() • if emitting object, createMCObjectStreamer() o This in turn calls createObjectWriter() and tells it to emit ELF32/ELF64 objects. This information comes from MipsAsmBackend and ultimately comes from Triple::mips/mipsel vs Triple:...

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

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because