similar to: [LLVMdev] adding multiple flavors to test suite

I ran into a case in Mips16 where I need two registers. The problem arises from the fact that SP is not a mips16 register. You can implicitly use it in load/store and, move it to/from a mips16 register and add small immediate values to it but that's it. It's not in general a problem for me because there are a bunch of mips32 registers that are hard to use in mips16 so at this time, I

So what I realized is that you can't use the simple scavenger trick where you create the virtual register and use the more advanced features. This is because you can't call forward() in any form if there are virtual registers being used by any of the instructions in the basic block. This will cause forward to fail. Maybe this is a bug in forward() On 02/05/2013 02:51 PM, Reed Kotler

Does not seem that anyone is using the more advanced features of RegScavenger On 02/05/2013 01:09 PM, reed kotler wrote: > I ran into a case in Mips16 where I need two registers. > > The problem arises from the fact that SP is not a mips16 register. > You can implicitly use it in load/store and, move it to/from a mips16 > register and add small immediate values to it but

No. forward() is working correctly. All virtual register references must be resolved before calling it. -Jim On Feb 5, 2013, at 4:05 PM, Reed Kotler <rkotler at mips.com> wrote: > So what I realized is that you can't use the simple scavenger trick where you create the virtual register and use the more advanced features. > > This is because you can't call forward() in any

I'm happy to send you my patch as it stands today. It's not cleaned up yet all or tested thoroughtly but you can look at what I'm doing and maybe suggest some alternate paths and if it's not a matter of redoing everything, I would consider making some changes. Here is a sample stub: Consider this line of code: extern float fpff(float); We have no idea if this is a mips16 or

On 04/24/2013 03:47 PM, Rafael Espíndola wrote: > On 24 April 2013 18:30, reed kotler <rkotler at mips.com> wrote: >> There are a lot of issues. >> >> For one, the function I'm compiling is a mips16 function but the stubs being >> created are mips32 functions. >> > This looks similar to thumb x 32 bit arm. Wouldn't a similar solution > work for

> We also wanted the stubs to be real functions to llvm. That allows them to > participate properly > in optimization of various levels (including LTO). They can even be inlined. > There are other > planned optimizations that would not work if they were not legitimate > functions. I am not saying that the functions should not exist in the IL, just that they should not be inline

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

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

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

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>

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

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> wrote: >>>> I'm working on mips16 hard float which at a first approximation is just >>>> soft

I have some stub functions that are essentially static, but they cannot be removed. What linkage type should I use in that case. Internal linkage appears to get the functions discarded if they are not referenced under certain optimizations. This is part of the gcc mips16 hack for floating point. For example, a function like floor from the math library will be called with an external

I'm implementing this unusual gcc form of mips16 hard float. I ran into one unexpected wrinkle. It effects efficiency as opposed to correctness but I'd like to figure out the best way to resolve it. The signatures for the libcall routines have floating point arguments in at least some situations. I have not fully examined if it's all of them. So in callinfo while I'm lowering

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

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

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