<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><div class="">On Oct 8, 2015, at 11:49 AM, Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 8, 2015 at 7:15 AM, Tim Northover via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 8 October 2015 at 03:31, Joerg Sonnenberger <<a href="mailto:joerg@britannica.bec.de" class="">joerg@britannica.bec.de</a>> wrote:<br class="">
> I think we are talking about two different things here. What I am<br class="">
> advocating is that callsite and function signature must have matching<br class="">
> ABI. I think we already enforce that for things like argument type, so<br class="">
> enforcing sret doesn't seem to be any different. I am not saying that<br class="">
> you should not be able to override it via manual bitcasting, but that's<br class="">
> a completely different topic. If you do that, you are on your own.<br class="">
<br class="">
</span>Unfortunately the two aren't separable because the sret isn't part of<br class="">
the function's type. You can't even write down a bitcast that adds or<br class="">
removes it:<br class="">
<br class="">
$ cat simple.ll<br class="">
define void @foo(void(i8*)* %fn) {<br class="">
%tst = bitcast void(i8*)* %fn to void(i8* sret)*<br class="">
ret void<br class="">
}<br class="">
$ opt -verify simple.ll -S<br class="">
opt: simple.ll:2:41: error: argument attributes invalid in function type<br class="">
%tst = bitcast void(i8*)* %fn to void(i8* sret)*<br class="">
<br class="">
So if you ban mismatches at call sites, you're banning the casts too.<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div><br class=""></div>Yuck. Yes, that's a very compelling argument. :) It really does seem that the attributes which are required to match should be part of the function type. Oh well -- removing the assert is definitely the way to go, then, in the current model.</div><div><br class=""></div><div>(And fixing clang so it emits the proper declare would be nice too, but I guess it doesn't really matter, since that isn't actually used for anything.)</div><div><br class=""></div></body></html>