[LLVMdev] adding IR attributes to llvm

[Reed Kotler]

One solution for now would be to add a new generic "target" attribute 
and then add a string component to AttrBuilder to be used for storing 
the value of the attribute.

Maybe the syntax would be target("mips16") or target("nomips16")

This is similar to what is done now for stack alignment.

It could be possible to allow a list of them.

On 01/11/2013 11:25 AM, Reed Kotler wrote:
> 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 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
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>