similar to: [LLVMdev] How to pick default floating point ABI?

On 06/12/2015 07:12 PM, Daniel Sanders wrote: > > Hi, > > I'm afraid targeting a 64-bit CPU and the O32 ABI is completely broken > at the moment, it's one of the very long-standing issues I'm working > towards. The main problem is that a lot of the internals of the Mips > LLVM backend derive their behaviour from the target CPU rather than > the target ABI.

On 06/16/2015 06:21 PM, Daniel Sanders wrote: > > > > the best I can suggest is to target mips2 and O32 > > > > It's not work for all, still get Assembler messages error on some > source files > > > > > Warning: float register should be even, was 7 > > Could you add –save-temps to the compiler command and send me the > command along with the

The term "target" is somewhat overloaded. When llvm-config tells you it was built with the X86 target, that actually includes a variety of closely related architectures, such as x86_64, i386, and so on. Within the x86_64 architecture, there are many individual processor implementations that LLVM understands, such as Skylake, Bulldozer, and many many more. What *clang* means by

We are trying to use LLVM (Clang as the C frontend) to generate code for 32-bit MIPS (little-endian)l, which can run on simplescalar 3.0 sslittle-na-sstrix platform. Can you advise what would be the right way to use the LLVM compiler infrastructure? The following is the one I used, but it appears that it produce the code in big-endian (and I wonder whether the calling convention is right.) To

It will produce little-endian code if you replace "mips" with "mipsel". 1. clang -ccc-host-triple mipsel-unknown-linux -ccc-clang-archs mipsel -O3 -S -emit-llvm foo.c -o foo.ll 2. llc -march=mipsel -mcpu=4ke foo.ll -o foo.s (the -march option is redundant) If you do not specify the target cpu with -mcpu, by default it will generate code for Mips1, which has not been tested as

- my old email address. The ISA_* classes might not be the best choice for this. There's an overall hierarchy and ordering to the ISA_* classes since they represent the generations of the MIPS ISA. If these extensions are available in Loongson chips based on MIPS32r1 and MIPS32r2 for example, it becomes difficult to describe with ISA_* classes without duplicating instruction definitions or

Hi LLVM developers, GCC[1] is able to use Loongson ISA[2] for instruction selection: $ cat hello.c #include <stdio.h> int main(int argc, char *argv[]) { printf("Hello World\n"); return 0; } $ gcc -O0 -S hello.c $ cat hello.s .file 1 "hello.c" .section .mdebug.abi64 .previous .nan legacy .gnu_attribute 4, 1 .abicalls

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

I am curious- what is the current status of the MIPS support in LLVM? I have a mipsel device and was wondering if I could compile code for it with clang. Would I have to implement a backend setup myself? Is there also an option to compile w/ clang on an x86 for Mipsel? Thanks in advance.

On Mon, Jul 27, 2009 at 8:56 AM, Carter Cheng<carter_cheng at yahoo.com> wrote: > Is there also an option to compile w/ clang on an x86 for Mipsel? A normal build of clang includes limited cross-compile support by passing in the "-ccc-host-triple" option, although it's still a bit of a work-in-progress. Nobody has added support for any Mips targets, but it's really

On Dec 10, 2012, at 1:15 PM, "Carter, Jack" <jcarter at mips.com> wrote: > 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 >

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

Jim, You are correct: MipsSubtarget. For llvm-mc we have a straight MCSubtargetInfo object. For llc we get a MipsSubtarget object which derives from MipsGenSubtargetInfo which derives from TargetSubtargetInfo which derives from MCSubtargetInfo. The patch I hope to send out for review will do this: Add a new data member to MCSubtargetInfo base class. It will be a set of integers that is used or

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

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

> 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

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

Hi Matheus, Thank you for your information! Do you known where do download MIPS ABI/EABI document? Thanks in advance! -- Best Regards, Yu Rong Tan On Thu, Jun 12, 2014 at 7:14 PM, Matheus Almeida <Matheus.Almeida at imgtec.com> wrote: > An assembler is the tool you're after. [And a linker if you want to have an executable in the end]. > > You can specify -filetype=obj to

On 7 December 2012 18:57, Carter, Jack <jcarter at mips.com> wrote: > Hi Rafael, > > There are a lot of flags. Here are the ones you ask about: > > -KPIC, -call_shared generate SVR4 position independent code > -call_nonpic generate non-PIC code that can operate with DSOs > -mvxworks-pic generate VxWorks position independent code > -non_shared

Hi Rafael, There are a lot of flags. Here are the ones you ask about: -KPIC, -call_shared generate SVR4 position independent code -call_nonpic generate non-PIC code that can operate with DSOs -mvxworks-pic generate VxWorks position independent code -non_shared do not generate code that can operate with DSOs -xgot assume a 32 bit GOT Just to make things fun, the SGI notion of cpic (call pic)