[LLVMdev] adding IR attributes to llvm

[Reed Kotler]

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
mips32 for both "mips16" and "nomips16".

Nomips16 means normal "mips32" mode at this time. (We are mimicking the 
way gcc handles
this and there is yet another mode call "micromips" which will 
complicate this naming convention
when it gets pushed upstream in gcc soon).

In some senses, attribute(mips16) could be interpretted as a suggestion, 
ala "register" variables in C but at this time the attribute is taken 
literally in gcc. Ultimately the compiler could chose on it's
own to use mips16 in response to optimization -Os.

Mips16 is really just a compressed instruction encoding (ala thumb1 for 
arm) that encodes
instructions in 16 or 32 bits (as opposed to mips32 which encodes them 
all in 32 bits).

I think that in reality you will get around a 30% compression by using 
mips16, depending on the
profile of the code you are compiling.

mips16 does have some special abi (and hence calling convention 
requirements) when the return type is float, double, complex and/or the 
first and/possibly second argument is float or double.
the interoperability of mips16 and mips32 creates some issues because 
mips16 has no floating point instructions or registers.

On 01/11/2013 04:51 AM, Justin Holewinski wrote:
> 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 designation is actually part of the function calling convention.
>
>
> On Fri, Jan 11, 2013 at 12:20 AM, reed kotler <rkotler at mips.com 
> <mailto:rkotler at mips.com>> wrote:
>
>     For target dependent function level attributes, do I need to
>     actually add them to the enumeration in attributes.h?
>
>     I have for example, mips16 and nomips16 as attributes.
>
>     Or is this supposed to be done with cc <n>
>
>
>
>
>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> -- 
>
> Thanks,
>
> Justin Holewinski

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/cba5d598/attachment.html>