[llvm-commits] [llvm] r38506 - in /llvm/trunk: lib/VMCore/Verifier.cpp test/Verifier/byval-1.ll test/Verifier/byval-2.ll test/Verifier/byval-3.ll test/Verifier/byval-4.ll
espindola at google.com
Tue Jul 17 08:29:45 CDT 2007
> 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
> > > (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...
Rafael Avila de Espindola
Google Ireland Ltd.
Registered in Dublin, Ireland
Registration Number: 368047
More information about the llvm-commits