Duncan Sands wrote:> Hi Jon, > >> What is the correct procedure for translating a function signature from >> a high-order language to LLVM? > > you have to do it carefully so that LLVM will end up producing object code > that conforms to the platform ABI. For example, suppose you are using cdecl > with a small struct (a pair of ints, say). Then your function should get two > integer parameters, which LLVM will assign to registers. If using a large > struct then use byval which will pass it on the stack. > > I know this is painful, hopefully LLVM will get some helpers for this one > day. The reason is that some ABIs make distinctions that don't exist at > the LLVM level. For example at least one ABI says that "complex" > ( { double, double } ) should be passed differently to a struct containing > a pair of doubles.Ugh, this isn't what I wanted to hear. Passing "complex" differently than a structure containing two doubles is a bad design, but alas, calling conventions are beyond our control. How many special cases like this are there? If "complex" is the only special case, LLVM could provide a complex type, which behaves like {double,double} in all respects except for calls. I recommend handling calling conventions entirely in the back end. Apart from calling conventions, the front end doesn't need to know the specific target, only the data layout and which intrinsics the target supports. This approach makes a clean division between the front end and back end. Best Regards, Jon
> > entirely in the back end. Apart from calling conventions, the front end > > doesn't need to know the specific target, only the data layout and which > > intrinsics the target supports. This approach makes a clean division > > between the front end and back end. > > If you want to map from a C type/calling convetion to LLVM IR, clang is a > good way to go. It isn't fully up to snuff with all the ABIs out there, > but will be doing much better over the next few months.How about extracting the clang code and turning it into a set of helper routines for people who want to be able to generate C compatible function signatures? Ciao, Duncan.
On Mon, 14 Apr 2008, Jon Sargeant wrote:> Ugh, this isn't what I wanted to hear. Passing "complex" differently > than a structure containing two doubles is a bad design, but alas, > calling conventions are beyond our control. How many special cases like > this are there? If "complex" is the only special case, LLVM couldThere are a huge number of special cases. Take a look at the craziness in the x86-64 ABI structure passing rules for an example.> entirely in the back end. Apart from calling conventions, the front end > doesn't need to know the specific target, only the data layout and which > intrinsics the target supports. This approach makes a clean division > between the front end and back end.If you want to map from a C type/calling convetion to LLVM IR, clang is a good way to go. It isn't fully up to snuff with all the ABIs out there, but will be doing much better over the next few months. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Apr 14, 2008, at 14:25, Jon Sargeant wrote:> Duncan Sands wrote: >> > >>> What is the correct procedure for translating a function signature >>> from a high-order language to LLVM? >> >> you have to do it carefully so that LLVM will end up producing >> object code that conforms to the platform ABI. For example, >> suppose you are using cdecl with a small struct (a pair of ints, >> say). Then your function should get two integer parameters, which >> LLVM will assign to registers. If using a large struct then use >> byval which will pass it on the stack. >> >> I know this is painful, hopefully LLVM will get some helpers for >> this one day. The reason is that some ABIs make distinctions that >> don't exist at the LLVM level. For example at least one ABI says >> that "complex" ( { double, double } ) should be passed differently >> to a struct containing a pair of doubles. > > Ugh, this isn't what I wanted to hear. Passing "complex" > differently than a structure containing two doubles is a bad design, > but alas, calling conventions are beyond our control. How many > special cases like this are there?llvm-gcc is probably your best reference on this matter.> If "complex" is the only special case, LLVM could provide a complex > type, which behaves like {double,double} in all respects except for > calls. I recommend handling calling conventions entirely in the > back end.This would be convenient, but is unfortunately not realistic. Consider that platform calling conventions are generally defined in terms of C data types. Since LLVM's data types are by design lower-level than C, they are insufficient to specify platform calling conventions. Therefore, the LLVM IR needs to be annotated. This is done through a variety of mechanisms: 'cc' 'byval' 'sret' aggregate return breaking up structs into multiple parameters merging structs fields into single parameters probably more. On the other hand, you need only consider this complexity when interoperating with C/C++; your language's own functions need only be self-consistent. — Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080414/8c4e5acf/attachment.html>