similar to: [LLVMdev] changing passes and changing subtargets on a per function basis

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.

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

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

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

On 04/01/2013 12:31 PM, Chandler Carruth wrote: > On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com > <mailto:nrotem at apple.com>> wrote: > > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if > the attributes changed). Do you have another solution in mind ?

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

Current ISelDagToDag is created once per module. The TargetLowering class is allocated there and register classes are added and the computeRegisterProperties is called. In order to switch back and forth between mips16 and mips32, I need to be able to reset what is done during computerRegisterProperties. Has anyone else looked into this for another port? Ideas? Mips16 is an instruction

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

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.

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

The problem is that everything about the mips32 and micro mips 16 instruction is the same, aside from the encoding in to binary. Seems like maybe we need to extend the notion of an instruction so that it can have alternate encodings depending on subtarget. On 09/05/2012 08:28 PM, Jim Grosbach wrote: > The instructions are defined by their encodings, not the assembly syntax. You want

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

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

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 Fri, Jan 20, 2012 at 1:59 PM, reed kotler <rkotler at mips.com> wrote: > 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.

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