llvm dev - Oct 2015 - SRET consistency between declaration and call site

On Wed, Oct 07, 2015 at 10:28:59AM +0200, Jonas Maebe via llvm-dev
wrote:
> 
> James Y Knight via llvm-dev wrote on Tue, 06 Oct 2015:
> 
> >Certainly a mismatch between sret and not-sret from caller to callee
could
> >not possibly work on sparc, because sparc's calling convention for
struct
> >return is totally bonkers.
> 
> It won't work on AArch64 either: it uses a fixed register to pass
struct
> return addresses, which is not used for other parameters under any
> circumstances.
That seems to make it a pretty good case for consider sret mandatory in
general.

Joerg

> That seems to make it a pretty good case for consider sret mandatory in
> general.
(Still) no more than any other type cast IMO. If you know what you're
doing you can cast function pointers (at the LLVM level), otherwise
you're going to get into trouble.

Tim.

On Wed, Oct 07, 2015 at 04:35:10PM -0700, Tim Northover
wrote:
> > That seems to make it a pretty good case for consider sret mandatory
in
> > general.
> 
> (Still) no more than any other type cast IMO. If you know what you're
> doing you can cast function pointers (at the LLVM level), otherwise
> you're going to get into trouble.
I think we are talking about two different things here. What I am
advocating is that callsite and function signature must have matching
ABI. I think we already enforce that for things like argument type, so
enforcing sret doesn't seem to be any different. I am not saying that
you should not be able to override it via manual bitcasting, but that's
a completely different topic. If you do that, you are on your own.

Joerg