similar to: Representing MIPS ABI information in the triple as ARM/X86 do for EABI/EABIHF/X32

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 is that IRLinker will link

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

Daniel: Thanks for your detailed response. I had seen the discussion from earlier this year, but when I read it, I didn't expect it would be so difficult to get just one bit of information where I wanted it. :-) Thanks for the heads up about clang not necessarily setting ABIname. I have at least enough of that working already that I can generate the appropriate assembly source. After doing a

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

> Why isn't the ABI reflected in the triple? Unfortunately, there's no easy answer to that. Some targets are better than others but generally speaking triples are very ambiguous. For example, in (most) GCC mips-linux-gnu/mips64-linux-gnu toolchains both triples produce 32-bit big-endian binaries for MIPS-I by default. Vendors can override the majority of this so it's entirely

Thanks Renato and Rafael. > 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

https://bugzilla.mindrot.org/show_bug.cgi?id=2590 Bug ID: 2590 Summary: Seccomp filter for missing architectures Product: Portable OpenSSH Version: 7.2p1 Hardware: Other OS: Linux Status: NEW Keywords: patch Severity: enhancement Priority: P5 Component: sshd

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

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

> > > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect. > > > > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. > > If it's something that's overridden later

> On Jan 7, 2020, at 13:57, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Jan 6, 2020 at 6:05 PM Daniel Sanders <daniel_l_sanders at apple.com <mailto:daniel_l_sanders at apple.com>> wrote: > > >> On Jan 6, 2020, at 14:29, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:

On Tue, Jan 7, 2020 at 5:27 PM Eric Christopher <echristo at gmail.com> wrote: > > > On Tue, Jan 7, 2020 at 3:18 PM Daniel Sanders via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Jan 7, 2020, at 13:57, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> >> On Mon, Jan 6, 2020 at 6:05 PM Daniel Sanders

Right. I think that's what we ended up doing rather than a more general attribute on the module itself. *shrugs* Probably ok? I'd probably prefer not to have to have target code to do the evaluation if possible, but everything is weird and an edge case - mips abis more than some :) -eric On Wed, Jan 8, 2020 at 8:58 AM David Blaikie <dblaikie at gmail.com> wrote: > Oh, I should

But then I should write // CHECK: something // SSE: something // SSE3: something With this feature it can be write // {{[A-Z0-9]+}} : something From: James Y Knight [mailto:jyknight at google.com] Sent: Thursday, May 26, 2016 5:53 PM To: Ehsan Amiri <ehsanamiri at gmail.com> Cc: Elena Lepilkina <Elena.Lepilkina at synopsys.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject:

> On Jan 6, 2020, at 14:29, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Mon, Jan 6, 2020 at 5:58 AM Zakk <zakk0610 at gmail.com <mailto:zakk0610 at gmail.com>> wrote: > > > David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> 於 2020年1月6日 週一 下午2:23寫道： > If this is something that can vary per

On Thu, May 26, 2016 at 10:35 AM, Ehsan Amiri via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 7. Wildcard for prefixes - If some statements should be checked > regardless prefix, it should be used //{{*}}, //{{*}}-NEXT, //{{*}}-SAME > and etc. > >> 8. Prefix with regular expressions - If statement should be >> checked if prefix matches some regular

> > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect. > > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect. > If it's something that's overridden later because it can't be

I also work on the RISC-V backend, and have been doing a little work on the ELF psABI document for RISC-V. I agree that, conceptually, the psABI choice should be in the module metadata. Zakk, however, has discovered a phase ordering issue within LLVM that relates to this approach. The phase ordering problem is that the LTO backend is currently setup without interrogating the current module for

Rewrote the ABI example in terms of clang -cc1as which is a supported tool. Note that the same problems exist and that they are unrelated to the existence of TargetMachine or not since TargetMachine gets the relevant information from the Triple it holds. This information is incorrect, even as a starting point. Please do read the other examples in my previous email. It contains a number of

Thank you very much for your information and documents! Why Imagination Technologies do not offer the latest MIPS ABI document download link just like the ISA docs? If they thought no much people interested in that doc, they had to make greate effort on compiler like GCC,LLVM by themself,then why GCC disagree with some MIPS ABI, it should be freely designed by MIPS ABI designer and compiler