similar to: [LLVMdev] how to add some default target flags?

Hello, I've built LLVM natively on a fpu-less (soft-float) mips32 target, and built mesa to use it. However llvm apparently cannot determine what machine it's running on and builds code for a generic mips target with fpu. Is there a way to have llc/llvm always use "-march=mipsle -mcpu=mips32 -mattr=+soft-float" as a default command line, something similar to gcc's

When a mips16 wants to return a floating point value, it's at a quandary in mixed mode programs (having both mips16 and mips32 code). float foo() { return 1.0; } Mips16 code is compiled in soft float, with there being an options to have the emulation library be written in mips32 and use floating point instructions in those mips32 support functions (if the machine supports floating

Is it possible to assign the value of subtarget features using more complex expressions with code as opposed to using the mechanism that tablegen affords. For example, if Mips16 or Micro Mips is not present, then I want the subfeature "standard encoding". If I can't do this, then it requires me to write a more complex expression for the "standard encoding" expresions.

I need to be able to emit .globl for the soft float routines used by mips16. The routines are called but there is no .globl definition for them. How can I do this? Background: I have a strange issue that I encountered with mips16 hard float. Part of mips16 hard float is to emit calls to runtime routines with the same signature as usual soft float routines, except that they are implemented

On Tue, Dec 23, 2014 at 09:27:32PM +0000, Daniel Sanders wrote: > clang+llvm-3.5.1-rc2-mips-linux-gnu.tar.xz: > All ok for default options and -mips32. > > clang+llvm-3.5.1-rc2-mipsel-linux-gnu.tar.xz: > All ok for default options. > It will take a couple days to get results for the -mips32 test-suite (there's no FPU or local disk on this machine so some tests

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:

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

Hi Reed, Still catching up on email, so hope this isn't already covered... reed kotler <rkotler at mips.com> writes: > I have a strange issue that I encountered with mips16 hard float. > > Part of mips16 hard float is to emit calls to runtime routines with the > same signature as usual soft float routines, except that they are > implemented using mips32 code which uses

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

> > > clang+llvm-3.6.0-rc2-mipsel-linux-gnu.tar.xz > > > All clear for default options. > > > Still running for the other configs. > > > > I just had to kill Searching-dbl.simple and Packing-dbl.simple for the > > mips32 config which were at 65hrs and 15hrs real time respectively. This is > > far in excess of the 15,000s time limit that's

I'm working on the mips16. Mips16 is a mode of the Mips32 (or Mips64) processor. For the most part, it is a compressed form of the MIPS32 instruction set, though not all instructions are supported. Most of the same opcodes and formats are present though sometimes with some restriction. (The micro mips architecture is a true 16 bit compressed form of MIps32 though also with some

On Jan 24, 2012, at 1:46 AM, Reed Kotler wrote: > Mips16 is a mode of the Mips32 (or Mips64) processor. For the most part, > it is a compressed form of the MIPS32 instruction set, though not all > instructions are supported. Most of the same opcodes and formats are > present though sometimes with some restriction. (The micro mips > architecture is a true 16 bit compressed form

I'm working on mips16 hard float which at a first approximation is just soft float but calls different library routines. Those different library routines are just an implementation (in mips32 mode) of soft float using mips32 hardware instructions. This part is already done. (mips16 mode has no floating point instructions). The next level of this that I am working on now is the ability to

What I am thinking of now is to just register the MIPS116 and MIPS32 DAGToDAGISel passes and then within run on machine function, I can just return if the current mode indicates that mips16 is needed for example, so the run on machine function for Mips32 would return immediately. On 03/27/2013 10:05 AM, Reed Kotler wrote: > I guess another way to do this is to just register both passes for

Hi, Mips32 has 64 bit floating point instructions, while i64 instructions have to be emulated with i32 instructions. This means that G_LOAD should be custom legalized for s64 integer value, and be legal for s64 floating point value. There are also other generic instructions with the same problem: G_STORE, G_SELECT, G_EXTRACT, and G_INSERT. There are also other configurations where integer

On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: > I'm working on mips16 hard float which at a first approximation is just soft > float but calls different library routines. Those different library routines > are just an implementation (in mips32 mode) of soft float using mips32 > hardware instructions. This part is already done. (mips16 mode has no

This seems to work okay. I register both the Mips16 and non Mips16 passes of the instruction selector and then those return false if they are not supposed to be running. Make-check at least passes in this case. So in principle turn on the dual mode now and debug whatever misc is left. For this I insert another pass before the mips16 and non mips16 passes. On 03/27/2013 10:19 AM, Reed Kotler

On Mon, Jan 7, 2013 at 4:16 PM, reed kotler <rkotler at mips.com> wrote: > On 01/04/2013 07:45 PM, Eli Friedman wrote: >> >> On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: >>> >>> On 01/04/2013 06:08 PM, Eli Friedman wrote: >>>> >>>> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com>

On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: > On 01/04/2013 06:08 PM, Eli Friedman wrote: >> >> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: >>> >>> I'm working on mips16 hard float which at a first approximation is just >>> soft >>> float but calls different library

So the switching between mips16 and mips32 on a per function basis seems to basically be working except that asm printer has some kind of issue here. I'm debugging that now. I get this: lc: /home/rkotler/workspace/llvmpb6/include/llvm/MC/MCStreamer.h:224: void llvm::MCStreamer::SwitchSection(const llvm::MCSection*): Assertion `Section && "Cannot switch to a null