similar to: [LLVMdev] adding IR attributes to llvm

Depends on whether its actually the calling convention, or just an annotation (I don't know MIPS that well). Could you ever have a case where you want to declare a function as both mips16 and fastcc, or some other explicit calling convention? For PTX, we added two calling conventions to mark kernel functions (callable by host) from device functions (not callable by host). But this

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

On 05/14/2012 02:42 PM, Jakob Stoklund Olesen wrote: > On May 14, 2012, at 2:28 PM, reed kotler wrote: > >> I'm not using getMinimalPhysRegClass. Some target independent code is using it. > Probably PEI. > >> It makes trouble for us and I would like to submit a patch to make it a virtual function so that I can override it and make it meaningful for Mips, as long as this

Reed, On May 14, 2012, at 3:45 PM, reed kotler <rkotler at mips.com> wrote: > On 05/14/2012 02:42 PM, Jakob Stoklund Olesen wrote: >> On May 14, 2012, at 2:28 PM, reed kotler wrote: >> >>> I'm not using getMinimalPhysRegClass. Some target independent code is using it. >> Probably PEI. >> >>> It makes trouble for us and I would like to

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

On May 14, 2012, at 2:28 PM, reed kotler wrote: > I'm not using getMinimalPhysRegClass. Some target independent code is using it. Probably PEI. > It makes trouble for us and I would like to submit a patch to make it a virtual function so that I can override it and make it meaningful for Mips, as long as this method still exists. > > I want to add another register class for

On 03/28/2013 12:22 PM, Nadav Rotem wrote: > Hi Reed, > > On Mar 28, 2013, at 12:18 PM, Reed Kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > >> As for the BasicTransformInfoPassass, for this dual mode I'm using >> createNoTargetTransformInfoPass right now. > > So, MIPS does not need LSR, LowerSwitch and other optimizations

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

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

So I have dual mode 16/32 compilation on a per function basis working. I need to clean up some things and then will push the change. I managed to do everything without needing to change anything in target independent code thus far. It was a fun puzzle to solve as to how to do this using only the given APIs. As for the BasicTransformInfoPassass, for this dual mode I'm using

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

Hi Reed, On Mar 28, 2013, at 12:18 PM, Reed Kotler <rkotler at mips.com> wrote: > As for the BasicTransformInfoPassass, for this dual mode I'm using createNoTargetTransformInfoPass right now. So, MIPS does not need LSR, LowerSwitch and other optimizations that depend on TTI ? > I will solve this issue of the BasicTransformInfoPass being immutable after this initial checking

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

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 >

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 ONE register class. That concept doesn't make sense any longer, as LLVM supports and

We already divided out our classes as you did for ARM. The problem here is that we have a store/load byte/halfword to/from a Frame object. We know at that time that it's not going to be possible to store it using SP because there is only such instructions for store/load of a word. What we would want to do is to move SP into a Mips 16 register and then do a indexed load/store off of that

Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it. There are