[LLVMdev] Optimization feasibility

[Joachim Durchholz]

Hi Arnold,

Arnold Schwaighofer schrieb:
> On 25 Dec 2007, at 03:29, Gordon Henriksen wrote:
> 
>> It also supports emitting tail calls on
>> x86, but its support is somewhat weak. This is partially mandated by
>> calling conventions, but those implementing functional languages might
>> be disappointed. Check the llvmdev archives for details.
>>
> Hi Joachim,
> I am  the person to blame for tail call support and its deficiencies  
> on x86.
> 
> The current constraints for tail calls on x86 are:
> 
> Max 2 registers are used for argument passing (inreg).

On a register-starved architecture like the x86, that's not too serious 
of a problem.

 > Tail call optimization is performed provided:
> * option tailcallopt is enabled

OK.

> * caller/callee are fastcc

Not sure what that means - I have to dig into the docs yet.

> * elf/pic is disabled (this should be the case on mac os x?) OR

Dunno, I don't have (or want) a Mac. (They are fine machines and all, 
but too expensive for my budget.)

> * elf/pic enabled + callee is in the same module as caller + callee has
>   visibility protected or hidden

Well, I'm not sure whether I will need or want to work with LLVM 
modules, so I don't know whether that will become a problem or not.

The audience I have in mind would mostly use Intel 32-bit, however, it 
would probably be a good idea to cover the 64-bit variants as well, 
since 32-bit will be dead or dying when (if) my project gets traction. 
In other words, I'll probably want to stay away from 
architecture-specific optimizations, unless they are really, really 
important, cover a really, really large part of the user base, and 
really, really don't place architectural constraints on the rest of the 
system.

> if you have got any questions regarding tail call stuff  i would be  
> happy to help

Not at the moment, no. My priorities are more on the frontend side right 
now; after that, I'll see how much interest the thing will generate, and 
*then* I'll start to look into optimization possibilities.
Besides, most of the project is just vaporware in my head right now. I 
wouldn't even know which questions to ask yet.

The one answer I really needed to know was whether the LLVM community is 
interested in this kind of problem. The response has convinced me that 
this is the case, so I'll use LLVM as a foundation.

Regards,
Jo