[LLVMdev] Function attributes and bytecode

[Chris Lattner]

On Thu, 10 Feb 2005, Alkis Evlogimenos wrote:
> On Thursday 10 February 2005 21:47, Markus F.X.J. Oberhumer wrote:
>> 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

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/