<div dir="ltr">+echristo who implemented some of this stuff a while back - I don't recall discussing this particular problem before, though... <br><br>(1) seems sort of plausible to me (speaking fairly naively) - do we correctly annotate function declarations with the attributes today? (eg: if test3 were defined in some other translation unit - would the declaration of test3 in this translation unit have the right avx attributes on it?)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 14, 2021 at 2:09 PM Nikita Popov via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,<br></div><div><br></div><div>Consider the following code:</div><br>target triple = "x86_64-unknown-linux-gnu"<br> <br>define void @test1() "target-features"="+avx" {<br>  call void @test2() <br>  ret void<br>} <br> <br>define void @test2() {<br>  call void @test3(<4 x i64> <i64 0, i64 1, i64 2, i64 3>)<br>  ret void<br>} <br> <br>define void @test3(<4 x i64> %arg) noinline {<br>  ret void <br>}<br><br><div>Inlining will inline test2 into test1, because test1 has a superset of target features:</div><div><br></div><div>target triple = "x86_64-unknown-linux-gnu"<br> <br>define void @test1() "target-features"="+avx" {<br>  call void @test3(<4 x i64> <i64 0, i64 1, i64 2, i64 3>)<br>  ret void<br>} <br> <br>define void @test2() {<br>  call void @test3(<4 x i64> <i64 0, i64 1, i64 2, i64 3>)<br>  ret void<br>} <br> <br>define void @test3(<4 x i64> %arg) noinline {<br>  ret void <br>}</div><div><br></div><div>Now we have a problem: X86 uses different vector ABIs depending on target features. test3 is compiled without avx, and as such expects the argument to be passed in two XMM registers. test2 is also compiled without avx and performs the call correctly. test1 on the other hand is compiled with avx and will instead pass a single YMM register.</div><div><br></div><div>Note that the by-value vector arguments do not necessarily have to be present in the original code -- even if the frontend passes all vectors by memory to avoid precisely this issue, argument promotion can convert them to by-value arguments, as the caller/callee ABIs match at the time argument promotion runs (between test2 and test3).</div><div><br></div><div>I would like to have some input on how this miscompile could be addressed. The two general options I see are:</div><div><br></div><div>1. Fix call lowering to respect callee target features. That is, even if the caller is +avx, if the callee is not then we should pass arguments via xmm rather than ymm. I'm not sure to what degree this is possible without our current infrastructure though.</div><div><br></div><div>2. Prevent inlining in this case. I don't think we can't prevent inlining across functions with different target features entirely, as that would be a performance disaster. But possibly we can inspect the body of the callee to check for calls that would be problematic under the new ABI.</div><div><br></div><div>Regards,<br></div><div>Nikita<br></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>