similar to: [LLVMdev] dynamic passes

not in this case. the architecture is changing on a per function pass. mips32->mips16->mips16.... same issue would be for arm->thumb1->arm On 03/29/2013 04:26 PM, Chuck Zhao wrote: > Can you do this instead: > > PassManager pm = ...; > pm.add(other needed passes); > ... > if(arch you are interested) > pm.add(your pass); > ... > pm.run(); > > >

In this case, you can specialize a few pass manager objects, each for a specific sub target type. E.g. PassManager pm0 = .. ; // for mips32; PassManager pm1 = .. ; // for mips16; ... if(function needs to run on mips32) pm0.run(); else if(function needs to run on mips16) pm1.run(); ... Of course, you have to figure out the suitable sets of functions for each sub target. Hope it helps.

This is what I'm doing right now and the only issues that came up in internal review is that we have to create the pass object now for things that we are unlikely to need. On 03/29/2013 04:05 PM, Chuck Zhao wrote: > I think you will have to add the passes anyway before asking the pass > manager object to run. > In addition, you can specify some dependency, so that that non relevant

Can you do this instead: PassManager pm = ...; pm.add(other needed passes); ... if(arch you are interested) pm.add(your pass); ... pm.run(); Chuck On 3/29/2013 4:15 PM, Reed Kotler wrote: > This is what I'm doing right now and the only issues that came up in > internal review is that we have to create the pass object now for things > that we are unlikely to need. > > On

I think you will have to add the passes anyway before asking the pass manager object to run. In addition, you can specify some dependency, so that that non relevant pass will not have a chance to run. The PassManager should be able to figure that out given the runtime conditions. Chuck On 3/29/2013 3:38 PM, reed kotler wrote: > Is it possible to dynamically add and remove passes once llc

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

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

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

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

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

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

We are starting to look at the mips16 and micro mips ports. There are various design issues that people may have some good input on. Especially in how to structure the TD files and other optimizer issues. Mips16 is sort of like thumb and Micro Mips like thumb2 as far as I understand. Mips16 or Micro Mips can live inside of either MIPS32 or MIPS64. In gcc, it's possible using attributes to

Seems like -femit-all-decls partially works around this. But I would still like to solve the real problem of creating a function which is local/static but which cannot be thrown away by the optimizer if not referenced. On 07/24/2013 04:07 PM, Reed Kotler wrote: > Maybe there is some attribute I can add this will not allow the function > to be discarded. > > On 07/24/2013 03:45 PM,

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

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

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 routines. Those different library routines >> are just an implementation (in mips32 mode) of soft float using mips32 >>

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

Maybe there is some attribute I can add this will not allow the function to be discarded. On 07/24/2013 03:45 PM, reed kotler wrote: > 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 >