similar to: [LLVMdev] Using llvm-mc assembler in the llvm test-suite

On Mon, Oct 15, 2012 at 2:22 PM, Carter, Jack <jcarter at mips.com> wrote: > Has anyone converted llvm/projects/test-suite to use the llvm assembler > instead of gcc? > > If so, what was needed to change and how? > > My assumption is that this would be a good way to test the llvm assembler. > Not quite sure what you mean, as far as I know there isn't any assembler

Yes, absolutely. There's two pieces of this that are handy. First, checking the normal integrated-assembler code path. That doesn't check the actual assembler, but rather the binary encoder and object file emitter. To test that, I did runs with a locally modified clang that enabled the integrated assembler by default for my target (ARM/Darwin at the time). The second piece is checking the

Let me see if I understand the response ;-) When you are saying integrated assembler do you mean llc --filetype=obj? If so, we currently have that for an option when running the test-suite. When you say that to test the llvm-mc assembler for your target you don't substitute the gcc assembler invocation for llvm-mc which would expect the resultant executable run to pass. Instead you have to

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

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

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 >

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)

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

I'm trying to build a standalone assembler for Mips using AsmParser. Following the lead of X86, ARM and MBlaze I have run tblgen -gen-asm-matcher on Mips.td to produce tables and methods to aid the parser (MipsAsmParser.cpp) which is a stripped down ARM implementation. I am getting an assertion for what I believe are multiple register definitions with the same name. llvm-tblgen:

Hi Jack, You're running into a fundamental problem with the current table generated asmmatcher. Specifically, wants to believe that assembly parsing is context insensitive, or at least close enough that operands can be parsed w/o knowing the context of the instruction. Its idea is to use the operand types to disambiguate which instruction should be selected. It sounds like MIPS 64vs.32 does

On Tue, Dec 11, 2012 at 2:48 PM, Carter, Jack <jcarter at mips.com> wrote: > Attached are the promised patches for the below proposed change. > Just a quick question from an initial review: isn't the int->bool mapping of flags a bit limiting. Flag can have actual values and not only be there or not be there. Wouldn't a more generic mapping (string->string ?) be more

Attached are the promised patches for the below proposed change. Cheers, Jack ________________________________________ From: Carter, Jack Sent: Tuesday, December 11, 2012 1:33 PM To: Jim Grosbach Cc: Rafael Espíndola; List Subject: RE: [LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter Jim, You are correct: MipsSubtarget. For llvm-mc we have a

On Jan 31, 2012, at 1:26 PM, Carter, Jack wrote: > I'm trying to build a standalone assembler for Mips using AsmParser. > > Following the lead of X86, ARM and MBlaze I have run tblgen -gen-asm-matcher on Mips.td to produce tables and methods to aid the parser (MipsAsmParser.cpp) which is a stripped down ARM implementation. > > I am getting an assertion for what I believe are

Older targets like Mips had/have assemblers and ABIs that carry a lot of baggage. The small bit of baggage that is giving me fits is that MipsELFObjectWriter needs to know the relocation model (static,pic,cpic), whether we are using xgot (-mgot), which abi (old,new), which architecture (32r[123],64[123]), which if any coprocessor or extention instructions are used (mips16,micromips,etc.). I

On Fri, Dec 14, 2012 at 1:03 PM, Carter, Jack <jcarter at mips.com> wrote: > Eli, > > This is the kind of feedback I want. I believe I have to add to the base class so it should be generally useful. I can see string being better for the value. I still am enamoured with an enumeration for the tab though: int->string. How would that be a limitation? > I guess that's fine,

On 6 December 2012 17:49, Carter, Jack <jcarter at mips.com> wrote: > Older targets like Mips had/have assemblers and ABIs that carry a lot of > baggage. > > The small bit of baggage that is giving me fits is that MipsELFObjectWriter > needs to know the relocation model (static,pic,cpic), whether we are using > xgot (-mgot), which abi (old,new), which architecture

Eli, This is the kind of feedback I want. I believe I have to add to the base class so it should be generally useful. I can see string being better for the value. I still am enamoured with an enumeration for the tab though: int->string. How would that be a limitation? How about the rest of the patch? I appreciate the feedback, Jack ________________________________________ From: Eli

Hi, I'm pleased to announce that the MIPS integrated assembler is now good enough to recurse the compiler for MIPS32R2, build a bootable Linux kernel for MIPS32R2, and pass LNT testing for a variety of 32-bit MIPS targets. I've therefore enabled it by default for all 32-bit MIPS targets in both LLVM and Clang. We're not aiming for perfect GAS compatibility but you should find that

Hi Jack, On Sat, Mar 2, 2013 at 8:15 AM, Jack Carter <Jack.Carter at imgtec.com> wrote: > Jia, > > I made what I believe to be the correct changes and rebuilt clang and llc. Are the results what you expected? I so I will prepare the patches for commitment. > > Jack > > clang ../mips_R_JiaLiu.c -o mips_R_JiaLiu.ll -emit-llvm -O3 -S -target mipsel-unknown-linux -std=gnu89

Eli, Yes, SubtargetInfo is more of a container of convenience since it is available to all the assemblers. Working with the current framework it seemed the least disruptive. I'll describe the problem again. The Mips ABI for better or worse, uses the ELF headers e_flags extensively. The most pressing issue is the need to post the relocation model such as PIC, CPIC or non-shared. The object