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

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

On 8 October 2015 at 03:31, Joerg Sonnenberger <joerg at
britannica.bec.de> wrote:
> 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.
Unfortunately the two aren't separable because the sret isn't part of
the function's type. You can't even write down a bitcast that adds or
removes it:

$ cat simple.ll
define void @foo(void(i8*)* %fn) {
  %tst = bitcast void(i8*)* %fn to void(i8* sret)*
  ret void
}
$ opt -verify simple.ll -S
opt: simple.ll:2:41: error: argument attributes invalid in function type
  %tst = bitcast void(i8*)* %fn to void(i8* sret)*

So if you ban mismatches at call sites, you're banning the casts too.

Cheers.

Tim.

On Thu, Oct 8, 2015 at 7:15 AM, Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 8 October 2015 at 03:31, Joerg Sonnenberger <joerg at
britannica.bec.de>
> wrote:
> > 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.
>
> Unfortunately the two aren't separable because the sret isn't part
of
> the function's type. You can't even write down a bitcast that adds
or
> removes it:
>
> $ cat simple.ll
> define void @foo(void(i8*)* %fn) {
>   %tst = bitcast void(i8*)* %fn to void(i8* sret)*
>   ret void
> }
> $ opt -verify simple.ll -S
> opt: simple.ll:2:41: error: argument attributes invalid in function type
>   %tst = bitcast void(i8*)* %fn to void(i8* sret)*
>
> So if you ban mismatches at call sites, you're banning the casts too.
>
I agree. Maybe a different analogy based on an FAQ[1] will work. sret is
similar to the function calling convention. The function calling convention
is, for reasons that I don't agree with, not part of the function type.
Therefore the verifier accepts direct calls to functions with mismatched
calling conventions, because it's not a type mismatch. The optimization
passes, however, will transform that call to unreachable.

I argue the same applies to sret. Because the verifier does not reject it,
we cannot assert on a mismatch later. We have to either make sret part of
the type system, so that mismatches cannot occur without a cast, or we have
to silently accept it and generate code that's probably incorrect.

[1]
http://llvm.org/docs/FAQ.html#why-does-instcombine-simplifycfg-turn-a-call-to-a-function-with-a-mismatched-calling-convention-into-unreachable-why-not-make-the-verifier-reject-it
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151008/39fae2e2/attachment-0001.html>