adding IR attributes to llvm

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>

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.

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.

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.

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.