similar to: [LLVMdev] subtarget features

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

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

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

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

Yes, you could have mips16 and fastcc. Mips16 just means that processor mode to execute that function is "mips16". So in a mips16 designated function, I will just emit mips16 instructions and in a "nomips16" function, just emit normal mips32 instructions. I tend to call this "mips32" normal mode, "standard encoding" because in reality the processor is

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

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 think that Bill Wendlings new attribute implementation would allow me to do this but it is not ready yet. Maybe it's okay to just add them to the list of function attributes as I suggested. But in the end, someone has to approve the checkin. On 01/11/2013 07:35 AM, Reed Kotler wrote: > Yes, you could have mips16 and fastcc. > > Mips16 just means that processor mode to execute

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

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

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

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

Hi all, I plan to deprecate the experimental microMIPS64R6 backend for the 5.0 release and remove it after the release. Currently there are no CPUs that use that particular sub-ISA which makes it difficult to justify the maintenance and parallel development effort. If there was a CPU design produced that did use microMIPS64R6, the backend could be restored from the archive. Any comments or

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.

Hi Rui, Rafael, You are reviewers of two MIPS related patches for LLD linker: - Handle cross-mode (regular <-> microMIPS) jumps https://reviews.llvm.org/D40147 - Multi-GOT implementation https://reviews.llvm.org/D31528 Both patches implement essential part of MIPS architecture. microMIPS is something like ARM Thumb. Multi-GOT support required to link any rather complex application

Depends on whether its actually the calling convention, or just an annotation (I don't know MIPS that well). Could you ever have a case where you want to declare a function as both mips16 and fastcc, or some other explicit calling convention? For PTX, we added two calling conventions to mark kernel functions (callable by host) from device functions (not callable by host). But this

For target dependent function level attributes, do I need to actually add them to the enumeration in attributes.h? I have for example, mips16 and nomips16 as attributes. Or is this supposed to be done with cc <n>

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

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)