search for: mctargetopt

...ough of that working already that I can generate the appropriate assembly source. After doing a little more investigation, I decided to take an approach that seems simpler than yours, as I'm only trying to solve my own problem. It relies on having things lower in the MC layer be able to query MCTargetOptions. This is my plan: Make a path from the callers of Target::createAsmBackend to get MCTargetOptions to the MCELFObjectTargetWriter subclass or some method in the creation chain: <client, e.g. llvm-mc> -> Target::createAsmBackend(..., MCTargetOptions) -> (*MCAsmBackendCtorFn)(...

Hi Eric, It's the unsolved problems on the pass-MCTargetOptions-everywhere path that are my main concern with that approach rather than the amount of work. The first problem is that the result of IRObjectFile::CollectAsmUndefinedRefs() depends on the ABI but IRObjectFile doesn't know it. How would you deliver the ABI to IRObjectFile? The second problem...

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

I am implementing a defined, but currently unimplemented by LLVM, ABI. This ABI differs from an existing ABI in its ELF object format by implementing a subset of an existing ABI, but encoded differently and by setting the e_ident EI_CLASS field. I am trying to use MCTargetOptions::getABIName to set a boolean in the modified subclass of MCELFObjectTargetWriter to indicate which relocation encoding to use. As far as I can determine by source examination and judicious use of a debugger there isn't a simple path from the command line and the setting of ABIname in MCTarg...

...IN32/GNUABI64. This can be as simple as adding: Triple ABITriple = TT.getABIVariant(ABIName); // ABIName can be the empty string to get the default ABI. if (ABITriple.getArch() != Triple::UnknownArch) { TT = ABITriple; ABIName = ""; // <- Only needed if this would end up in MCTargetOptions::ABIName. } to the appropriate place in the caller. This is the same way clang handles the -m32, -m64, -EL, and -EB options with those options using get32BitArchVariant(), get64BitArchVariant(), getLittleEndianArchVariant(), and getBigEndianArchVariant() respectively to transform the triple f...

On 03/16/2017 06:22 PM, Mehdi Amini via llvm-dev wrote: >> On Mar 16, 2017, at 10:29 AM, Roger Ferrer Ibanez via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I'm implementing interleaved source in assembly output. Early reviews raised the concern > Is there a patch up for review? https://reviews.llvm.org/D30898

...t 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); } The callee owns the resulting object so ideally we would return a unique_ptr<MCAsmBackend>, but to do this we'd need access to the definiti...

...s namespace)::TestAsmParser::ComputeAvailableFeatures(unsigned long) const'* collect2: error: ld returned 1 exit status ---------------- and here is the code that it refers to: TestAsmParser(MCSubtargetInfo &sti, MCAsmParser &parser, const MCInstrInfo &MII, const MCTargetOptions &Options) : MCTargetAsmParser(), STI(sti), Parser(parser) { // Initialize the set of available features. setAvailableFeatures(ComputeAvailableFeatures(STI.getFeatureBits())); } Destructors for both TestAsmParser and MCTargetAsmParser class are available. I am using CMake....

...t cs.uiuc.edu] On Behalf Of Eric Christopher Sent: 28 January 2015 00:00 To: Vladimir Medic; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [Mips][TargetOptions] How to properly instantiate TargetOptions in MC layer? You can't really get there from here is the short answer. You can possible get MCTargetOptions, but then you need to change all of the constructors and calls across all of the backends to do this. I fixed all of the things that are currently in tree - what are you seeing or what do you need migrated around? -eric ps. Also, cc'ing me on it would have likely gotten you a faster answ...

...e (this one and the exception TType encoding being ABI dependant) and I've mixed them together in my original email. The split I should have described is that the label prefix is '$' for O32 and '.L' for N32/N64. Unfortunately O32/N32 are ELF32 and N64 is ELF64. I tried passing MCTargetOptions::ABIName down to the MCAsmInfo but ran into problems with some users of MCAsmInfo not initializing MCTargetOptions. There is also a problem with some users of MCAsmInfo not knowing the ABI. For example, llvm-objdump doesn't know the ABI until it starts reading the object file but has to ini...

...compiling the kernel with clang: A bisection points to 475ac5d302ba84ac13d34a9215c29c1a38ca5690 is the first bad commit commit 475ac5d302ba84ac13d34a9215c29c1a38ca5690 Author: Eric Christopher <echristo at gmail.com> Date: Thu May 15 01:10:50 2014 +0000 Unify command line handling of MCTargetOptions and remove extra options and code. No functional change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 208833 91177308-0d34-0410-b5e6-96231b3b80d8 8454a4b9373bca5d2a8f596ef1c33826171729bd is the first bad commit commit 8454a4b9373bca5d2a8f596ef1c33826171729bd Author...

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

...t cs.uiuc.edu] On Behalf Of Eric Christopher Sent: 28 January 2015 00:00 To: Vladimir Medic; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [Mips][TargetOptions] How to properly instantiate TargetOptions in MC layer? You can't really get there from here is the short answer. You can possible get MCTargetOptions, but then you need to change all of the constructors and calls across all of the backends to do this. I fixed all of the things that are currently in tree - what are you seeing or what do you need migrated around? -eric ps. Also, cc'ing me on it would have likely gotten you a faster answ...

...p step 2.) > > In `lib/Linker` (i.e., `llvm-lto`, `llvm-link`, `libLTO.dylib`), > defaults should be pushed down as explicit function attributes. > I think there are a few options/backend communications that aren't/haven't gone this way yet that are probably worth considering: MCTargetOptions/TargetOptions: Basically a grab bag of functionality, some of which is duplicated via attributes and some that's not. I think at least some of these should be replaced by module flags, e.g. ABI. Random backend flags: Anything for debugging. I'm thinking things that are either set as I...

Hi, I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select

...`llvm-lto`, `llvm-link`, `libLTO.dylib`), > > defaults should be pushed down as explicit function attributes. > > > > I think there are a few options/backend communications that > aren't/haven't gone this way yet that are probably worth considering: > > > > MCTargetOptions/TargetOptions: Basically a grab bag of functionality, > some of which is duplicated via attributes and some that's not. I think at > least some of these should be replaced by module flags, e.g. ABI. > > > > Random backend flags: Anything for debugging. > > > >...

..., `libLTO.dylib`), >> > defaults should be pushed down as explicit function attributes. >> > >> > I think there are a few options/backend communications that >> aren't/haven't gone this way yet that are probably worth considering: >> > >> > MCTargetOptions/TargetOptions: Basically a grab bag of functionality, >> some of which is duplicated via attributes and some that's not. I think at >> least some of these should be replaced by module flags, e.g. ABI. >> > >> > Random backend flags: Anything for debugging. >...

Hi all, Thank you so much for this discussion. It has been very helpful and educational. I think that I understand the perspectives of both Tim and Renato. Let me briefly summarize them to ensure that I correctly understand: Renato’s perspective is that the triple means whatever the author says it does, and that may or not be meaningful. :) In the case of armv7l (for example) it has a clear

Dear Developers, I compile a OpenCL kernel, FFT, in AMDAPP SDK v2.5 using clang 3.8 + libclc and assembling the code with lld (The LLVM linker). The assembly code contains the following assembly codes (and lots of other similar format assembly) that fails to be parsed by AMDGPUAsmParser. It seems to me that both are valid instructions after looking at the SI instruction spec. s_mov_b32 s0,

...`llvm-link`, `libLTO.dylib`), >>> defaults should be pushed down as explicit function attributes. >>> >>> I think there are a few options/backend communications that aren't/haven't gone this way yet that are probably worth considering: >>> >>> MCTargetOptions/TargetOptions: Basically a grab bag of functionality, some of which is duplicated via attributes and some that's not. I think at least some of these should be replaced by module flags, e.g. ABI. >>> >>> Random backend flags: Anything for debugging. >>> >>&...