On Monday 21 July 2008 08:37, Matthijs Kooijman wrote:> This pass only operates on internal functions, though, so it does not have > to deal with ABI issues. If you want to support the C ABI (which requires a > pointer in the first argument to return any struct AFAIK), you might be > better off generating such code in your frontend. Any internal function can > then be simplified by the sretpromotion pass (perhaps it could be modified > to take an option for the maximum number of elements to put in the real > return struct?)This is not the same on all architectures. For x86-64, for example, structs are returned through the hidden first argument except if they are small enough, in which case they are returned in registers. I'm rather worried about Chris' statements regarding ABI compliance. This is a very important issue for us and I would guess most commercial vendors. We absolutely must be able to interoperate with third-party libraries. Yes, we can implement the functionality ourselves but better that we have one community-owned implementation than a bunch of private forks. I'm hoping we can collectively discuss some of this at the dev meeting. -Dave
On Jul 21, 2008, at 1:19 PM, David Greene wrote:> This is not the same on all architectures. For x86-64, for example, > structs > are returned through the hidden first argument except if they are > small > enough, in which case they are returned in registers. > > I'm rather worried about Chris' statements regarding ABI > compliance. This > is a very important issue for us and I would guess most commercial > vendors. > We absolutely must be able to interoperate with third-party libraries.David, I'm not sure I follow. It is, of course, very important for us that llvm-gcc generate ABI compliant code on x86-64. I'm just saying that if struct-return does not provide the ABI required for a specific source construct that another lowering would be needed. In the case of X86-64, llvm-gcc does use aggregate return (for the interesting cases which return things in registers) and it does do the right thing. However, returning a {i64, i64, i64, i64} by value and having it automatically be returned "by pointer" is less interesting, as we already have a direct way to handle that (and llvm-gcc already produces it). AFAIK, llvm-gcc/g++ does an *extremely* good job of matching the X86-64 ABI on mainline. -Chris
On Tuesday 22 July 2008 01:23, Chris Lattner wrote:> David, I'm not sure I follow. It is, of course, very important for us > that llvm-gcc generate ABI compliant code on x86-64. I'm just saying > that if struct-return does not provide the ABI required for a specific > source construct that another lowering would be needed.Ah, ok. I misunderstood your statement.> In the case of X86-64, llvm-gcc does use aggregate return (for the > interesting cases which return things in registers) and it does do theI don't follow. By "aggregate return" do you mean "structs as first class values?" That is, llvm-gcc generates a return of a struct by value?> right thing. However, returning a {i64, i64, i64, i64} by value and > having it automatically be returned "by pointer" is less interesting,What do you mean by "less interesting?"> as we already have a direct way to handle that (and llvm-gcc already > produces it).So by, "direct way," you mean, "by using llvm-gcc?" Unfortunately, that doesn't work for everyone. It seems to me that target-specific issues like ABI compatibility should be handled by llvm directly.> AFAIK, llvm-gcc/g++ does an *extremely* good job of matching the > X86-64 ABI on mainline.But that's all implemented within llvm-gcc. LLVM codegen right now does not implement the ABI correctly. Apologies if I've misunderstood things again. I'm trying to get clarity on this issue. -Dave