> I see now that I was mislead by the assertion message which should probably > be "Attribute ByVal should not apply to function return values!". I thought > you were not allowing this attribute on any parameter of a function. By the > way, do you catch the case in which a parameter is marked both sret and byval? I don't. Good catch.
> I see, thanks for this information. However this seems to be more or > less exactly the scheme I was suggesting: an explicit copy of the struct > is made in the IR (done by the caller). In the IR the copy is passed to > the callee via a pointer which is marked byval. In the x86_64 code > generator the byval parameter is changed from a pointer to the copy > into whatever special form is required (I didn't understand exactly > how it is supposed to be passed: as an offset from the stack frame? > If so the stack pointer is subtracted from the pointer to the copy, > and the difference is passed). You still have the problem that the caller must generate the copy into the correct place in the stack frame. That is why I think this is a all or nothing situation. We can have the FE handle the stack frame or the backend. Using a mix will create a lot of dependencies between them. > > > (4) it conceptually unifies the treatment of ByVal and StructReturn > > > parameters. > > > > Which might not be generic enough. I can imagine a ABI were two > > passing structures to a function is handled in a different way then > > returning structures. > > It unifies them at the IR level not at the codegen level. > > Anyway, I have to say that my suggested scheme seems similar to your idea of > passing > the stack pointer as an explicit argument. > > Finally, in order for my scheme to generate efficient code it needs to be > possible to > eliminate pointless copies. These occur for example on a platform where a > by-copy struct > which is two words in size is supposed to be passed in two particular > registers. At the > codegen level the explicit copy in the IR (presumably a memcpy) will be > lowered to explicit > stores (to the stack) for a struct of this size. The target will lower the > byval call to a > load of the required registers from the stack followed by the call. How to > eliminate storing > the values to the stack and then reading them out again? As far as I know > LLVM codegen > will not eliminate stack stores and reads even if they could in theory be > turned into > stores to and reads from a virtual register. I guess this is why Chris noted > elsewhere > that eliminating pointless copies is hard... > > Ciao, > > Duncan. > Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047 _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
