similar to: [LLVMdev] some questions about the best place to put some passes

On 05/14/2012 02:17 PM, Jakob Stoklund Olesen wrote: > On May 14, 2012, at 1:02 PM, reed kotler wrote: > >> Does anyone understand the purpose of : >> >> TargetRegisterInfo::getMinimalPhysRegClass ??? > Barely. > >> Why is there the presumption to use the minimal subclass? > The function can be traced back to a time when men were men and registers belonged to

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 >

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

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

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,

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.

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

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

Mips16 mode has no floating point instructions. (Remember that mips16 is just an alternate decoder mode for the processor, mips32 or mips64 is the base processor). Currently with gcc for mips16, when there is floating point it generates a function call to emulate each floating point instruction. For mips 16 in llvm I want to just compile any function that has floating point, in mips32 mode.

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 > hardware instructions. This part is already done. (mips16 mode has no

For example: /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float 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

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

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

On 01/29/2014 02:32 PM, Eric Christopher wrote: > On Wed, Jan 29, 2014 at 2:27 PM, reed kotler <rkotler at mips.com> wrote: >> On 01/29/2014 02:18 PM, Rafael Espíndola wrote: >>>> >>>> I'd like to just check my code in and then you can look at it in it's >>>> totality and see if you have >>>> a better solution . >>>

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>

This came about in trying to implement some stubs used by gcc mips16 for allowing floating point interoperability with mips32. You get the following looking code from gcc -mips16: # Stub function for foovf (float) .section .mips16.fn.foovf,"ax", at progbits .align 2 .set nomips16 .set nomicromips .ent __fn_stub_foovf .type __fn_stub_foovf, @function __fn_stub_foovf: la

I'm starting to look more seriously at the problem of being able to running TargetLowering on a per function basis. In particular, I want to be able to compile functions as mips16 or mips32 , mixing them within a single compilation unit. It would be great if some more experienced people in this overall structure of the compiler would give their 2c because I'd hate to spend a lot of