similar to: Integrated Assembler is now the default for mips-* and mipsel-* triples.

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

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

> > 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. > > I believe we're going to disagree here as the TargetMachine does not get all of its > information from the Triple -

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

Eric Christopher echristo at gmail.com<mailto:echristo at gmail.com> writes: > The lack of a TargetMachine at the MC level was something I brought up a long time ago in this thread > with my proposed solutions. This is what needs to be fixed, especially given that targets can switch ISA, > ABI, floating point, etc within a single assemble action. I’ve been watching this thread in

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

> OK, I'm going to just reply to the last because I think it's the most important part of all this and would like to try to have us side tracked again. If you'd like I can reply to it, but let's take the last part first :) > > > > Could you please provide some examples of things that are impossible right now > > > with command lines, how those interact with

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

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

> So in summary, each step is ABI compatible with the previous step. The linker will ensure that the end-user doesn't try to do the second step before the first step is finished since it will refuse to link a binary that contains both O32 and O32+fp64. It will produce an O32 binary given a combination of O32+fpxx, and similarly a O32+fp64 binary given a combination O32+fpxx and O32+fp64.

> > (from the context, you might have meant 'tuple' where you've written 'triple'. I'm answering based on the assumption you meant 'triple') > I did mean what I wrote. I thought I ought to check since it's very easy to mix up triples and tuples and the context sounded off. I'm glad I picked the right assumption. > > The proposed TargetTuple

On Wed, Jun 18, 2014 at 2:03 AM, Matheus Almeida <Matheus.Almeida at imgtec.com> wrote: >> Why Imagination Technologies do not offer the latest MIPS ABI document download link just like the ISA docs? > It's something we're considering to do and the documents should be available at some point in the [hopefully] not too distant future. > >> then why GCC disagree with

> 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

On Mon, Jun 23, 2014 at 2:45 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >> There are a lot of MIPS ABIs. > > Yes, and we've discovered that there seem to be incompatible extensions to some of these ABI's too. :) > >> I'm pretty sure Imagination Technologies working up a new abi right now. > > Not exactly. We're not working on any

Hi Eric, The main thing we need to fix is that the selection between ELF32/ELF64 needs to depend on the ABI being N64 and not on whether we used a mips-linux-gnu triple versus a mips64-linux-gnu triple. So 'clang -target mips-linux-gnu' -mips64r2 -mabi=64' should produce an ELF64 and 'clang -target mips64-linux-gnu -mips32r2 -mabi=32' should produce an ELF32. In terms of code,

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

> -----Original Message----- > From: Tom Stellard [mailto:tom at stellard.net] > Sent: 24 November 2014 17:15 > To: Daniel Sanders > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > Subject: Re: Proposed patches for Clang 3.5.1 > > On Mon, Nov 24, 2014 at 04:33:28PM +0000, Daniel Sanders wrote: > > Hi, > > > > I'd like to propose the

Here are some examples using the gnu assembler reacting to the same input file with different commandline options. These are using the GCC assembler on hello.c // abi o32, arch mips32r2, relocation model pic+cpic mips-linux-gnu-as -mips32r2 -EL -KPIC -o hello_gas.o hello_gas.s e_flags 0x70001007 EF_MIPS_NOREORDER EF_MIPS_PIC EF_MIPS_CPIC E_MIPS_ABI_O32 EF_MIPS_ARCH_32R2 // abi

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: