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/