similar to: [LLVMdev] changing register classes on a per function basis

I added one method which clears the list of register classes. Then there is a change to mips16 code which simulates switching from mips32 to mips16 mode in the same module. It seems to work fine in that I can run this version of llvm for mips16 and it works identical to the one without this code. Beyond the "make check" I have run test-suite against this version. We could just

Just realized that BasicTransformInfoClass is an immutable pass. Not sure how to reconcile this with fact that there will be different answers needed depending on the subtarget. Seems like BasicTansformInfoClass should become a function pass that does not modify anything. On 03/22/2013 09:43 AM, Reed Kotler wrote: > Another way to do this would to be to have a reset virtual function >

Hi Reed, We will need to reconstruct the target machine and the TTI chain when the function attributes change. We currently don't have code for doing that but I suggest that you talk with Bill Wendling about the best way to implement this. Thanks, Nadav On Mar 22, 2013, at 11:30 AM, Reed Kotler <rkotler at mips.com> wrote: > Just realized that BasicTransformInfoClass is an

For being able to change subtargets within a compilation unit, among other things, I need to be able to change the target lowering class that is used by BasicTTI For example we have a mips16 and non mips16 version. On the original call that creates this class, I'd like to pass the address of the address of the TargetLoweringBase class. That way I can insert a function pass before this

Another way to do this would to be to have a reset virtual function which is passed the Function, and the address of TLI so that it could be modified. This seems somewhat cleaner. The reset virtual function would be added to base class TargetLoweringBase. On 03/22/2013 09:22 AM, reed kotler wrote: > For being able to change subtargets within a compilation unit, among > other things, I

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

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.

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

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

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

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

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

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

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

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

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>

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

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