similar to: [lld] Any chance to get review for a couple of patches in a couple of years?

Hi, Yes I'll do that. The situation has changed a lot since then and lld got support for other architectures, in particular aarch64. But if I remember correctly, there was a discussion whether we should bring this ABI oddness to the ABI standard body (if exists) or not. I wonder if there was some progress on that. On Mon, Apr 23, 2018 at 10:28 AM Simon Atanasyan <simon at

Hi, Sorry for the late report but I've only just found these issues. Llvm.org isn't working for me at the moment but I'll file tickets once it is. The issues are: 1. Almabench has some significant numerical differences and fails the reference check for some configs. I'm investigating this one at the moment but early indications are that it's a similar (but different)

I believe I've identified the problem with almabench but I haven't found the root cause in the compiler yet. The problem is that a caller saved register ($f14) is being moved across a call and this call sometimes clobbers the value. As a result, the value of the TWOPI constant used in the fmod() calls isn't always 2*PI. According to -print-after-all, the pass that moves the

#1 is the most important but I'm already debugging that. I don't want to interrupt your holiday but if you could look at #3 that would be great. > As to the issue #3 - do we need to keep compatibility with the old mips-mti-linux-gnu toolchain layout? It would be nice to support both the old and new layouts but I doubt that's possible with the current framework (see below). If

Hi Daniel, I am on a vacation now till the Aug 3 but I can take a look at these problems. What is the most important? As to the issue #3 - do we need to keep compatibility with the old mips-mti-linux-gnu toolchain layout? Simon On Wed, Jul 29, 2015 at 1:08 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > The issues are: > > 1. Almabench has some significant

To reduce memory consumption clobbered registers are handled with RegisterMask machine operands which contain a bitset of all registers clobbered. - Matthias > On Jul 29, 2015, at 3:00 PM, Daniel Sanders <daniel.sanders at imgtec.com> wrote: > > I believe I've identified the problem with almabench but I haven't found the root cause in the compiler yet. > > The

Thanks. This is making a lot more sense now and it's looking like this issue isn't Mips specific. Here's the IR dump before simple register coalescing (note: I've patched the IR printer to print the contents of the regmask): 4480B %vreg260<def> = LDC1 %vreg253, <cp#3>[TF=6]; mem:LD8[ConstantPool] AFGR64:%vreg260 GPR32:%vreg253 4496B %vreg261<def> = FMUL_D32

Hello Daniel, At the moment we are preparing the patch for disassembling microMIPS 16 bit instructions and it will be on Phabricator tomorrow or on Wednesday. Functionality is implemented in MipsDisassembler::getInstruction where first two bytes are read and decodeInstruction is called with DecoderTableMicroMips16 and only if it fails we read 4 bytes and call decodeInstruction with

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.

Hi, We have this line in micromips-16-bit-instructions.s # CHECK-EB: addu16 $6, $17, $4 # encoding: [0x07,0x42] However, when I check this with llvm-mc, like below, I dont get back the assembly. This is against the latest LLVM code. What is wrong here? Thanks, Jun $ echo "0x07,0x42"|./Release+Asserts/bin/llvm-mc -disassemble -triple=mips -show-encoding -mattr=micromips

> > > 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 implementing this ability to switch between mips16 and mips32 on a per function basis. One issue that I've run into is regarding the DAGToDAGIsel pass. We have a different subclass for mips16 and non mips16 ( conceivably later there could be a separate one for micromips). I need to run a different pass depending on whether it's mips16 or mips32. My initial plan was to create

Micro mips is really 100% .s compatible with mips32. There are no register field size constraints and such. It's a strict superset of mips32. For the gcc port, the assembler is basically the only thing we changed. The gcc port was just adding the ".micromips" directive to the .s file and maybe some tiny driver work. That is the quandary. The entire .td file would have to be

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

Well, Requires is just a fancy way to add predicates. For mips16 and micro mips, we want to use them in a similar way as ARM does, I think, to how they are used for thumb and thumb2. The problem lies with tablegen. Whenever predicates are overriden by a derived class, it overwrites the previous definition. There is no way, it seems, to add to an existing list as you further derive classes.

I'm implementing this capability to allow switching between mips32 and mips16 code generation on a per function basis (should be useful for arm to thumb switching too). The problem is that while various things are done on a per function basis, there are two passes registered on a per module basis (target lowering and instruction selection). With the new attribute scheme, we can wake up

My understanding was that micro mips was similar to Thumb2, in that the smaller encodings have constraints on which registers can be read/written, because of the narrowing of the register fields in the encoding. If that's the case, then it definitely makes sense to model the micro mips instruction set as distinct from the mips32 instruction set, in basically the same way that Thumb2 is done.

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

I guess another way to do this is to just register both passes for mips16 and mips32 and have them return immediately if it is not their turn to run. On 03/27/2013 08:58 AM, Reed Kotler wrote: > I'm implementing this ability to switch between mips16 and mips32 on a > per function basis. > > One issue that I've run into is regarding the DAGToDAGIsel pass. > > We have a

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