Function attributes and bytecode

Project Infrastructure LLVM Dev List Archives
1

In order to get more familiar with the llvm sources I've recently
decided to try to add support for the always_inline and noline function
attributes.

I believe it is better to let the compiler decide when or not to inline a
function. Most of the times a developer goes overboard with inlining and ends
up with a lot of duplicated code that performs worse (this happened in the
company I used to work for).

While the core implementation does not look very complicated both on the
gcc and llvm side it seems that there are no provisions in the bytecode
to actually store such additonal information (need 2 bits in this case).
Did I miss something ?

If not, are there any plans to enhance the bytecode for function, type
and variable attributes ? Calling convention (cdecl, stdcall, ..) will
sooner or later be needed for Windows, ELF visibility would be nice, and
   things like packed/aligned are often required when talking to the OS
or some other library.

The is a plan to add calling conventions to llvm functions. See:

http://nondot.org/sabre/LLVMNotes/CustomCallingConventions.txt

If you are interested in tackling this it, it would be a great contribution to
LLVM!

Even if llvm basically does ignore any "unsupported" attributes the
CWriter could still use a number of them without major changes.

This will limit the C backend's portability. We would like to avoid using
anything out of ANSI C if we can.

2

In order to get more familiar with the llvm sources I've recently
decided to try to add support for the always_inline and noline function
attributes.

I believe it is better to let the compiler decide when or not to inline a
function. Most of the times a developer goes overboard with inlining and ends
up with a lot of duplicated code that performs worse (this happened in the
company I used to work for).

FWIW, I agree in principle, but in practice, these sorts of things can be very useful. For example, no_inline can be used to disable inlining of relatively small but known cold functions. always_inline is much more questionable to me, but I can see some uses for it.

While the core implementation does not look very complicated both on the
gcc and llvm side it seems that there are no provisions in the bytecode
to actually store such additonal information (need 2 bits in this case).
Did I miss something ?

If not, are there any plans to enhance the bytecode for function, type
and variable attributes ? Calling convention (cdecl, stdcall, ..) will
sooner or later be needed for Windows, ELF visibility would be nice, and
   things like packed/aligned are often required when talking to the OS
or some other library.

The is a plan to add calling conventions to llvm functions. See:

http://nondot.org/sabre/LLVMNotes/CustomCallingConventions.txt

If you are interested in tackling this it, it would be a great contribution to
LLVM!

I agree with Alkis here, if you wanted to work on adding support for Custom calling conventions, that would be a HUGE contribution and would make many people happy (it's the biggest part of getting 'guaranteed efficient tail calls' for example). Another one that would be useful is
first class alignment support:

http://nondot.org/sabre/LLVMNotes/LLVMAlignment.txt

Even if llvm basically does ignore any "unsupported" attributes the
CWriter could still use a number of them without major changes.

This will limit the C backend's portability. We would like to avoid using
anything out of ANSI C if we can.

I disagree here. So far, LLVM has had a policy against adding wierd and potentially random attributes to functions and other objects. I think this is the right thing to do for most cases, but again, there can be uses. I suspect that we *will have to* add attributes at some point, but that will be a fairly big decision and should be done right. I'm not sure if it's a "beginner" project...

When we have these attributes, I wouldn't have a problem with getting the CBE to emit them. We already conditionally emit GCC specific directives in some cases, I don't see how it would be any different for global object directives.

-Chris