rnk accepted this revision.
rnk added a comment.
Here's a thought. What happens if different TUs observe different overload
sets, perhaps because of ifdefs? Different TUs will generate different
resolvers, but they won't dispatch to the same sets of targets. I'm guessing
we'd treat that as an ODR violation, no diagnostic required?
Anyway, I think this is ready to commit. Thanks!
================
Comment at: test/CodeGen/attr-target-mv-va-args.c:41-44
+// WINDOWS: call i32 (i32, ...) @foo.arch_sandybridge
+// WINDOWS: call i32 (i32, ...) @foo.arch_ivybridge
+// WINDOWS: call i32 (i32, ...) @foo.sse4.2
+// WINDOWS: call i32 (i32, ...) @foo
----------------
Probably worth matching out the musttail for variadics, since the ellipsis
doesn't make sense without it.
================
Comment at: test/CodeGenCXX/attr-target-mv-inalloca.cpp:45-47
+// WINDOWS: musttail call i32 @"?bar@@YAHUFoo@@@Z.arch_ivybridge"(<{
%struct.Foo }>* %0)
+// WINDOWS: musttail call i32 @"?bar@@YAHUFoo@@@Z.sse4.2"(<{ %struct.Foo }>*
%0)
+// WINDOWS: musttail call i32 @"?bar@@YAHUFoo@@@Z"(<{ %struct.Foo }>* %0)
----------------
I think it's worth matching the retval and doing CHECK-NEXT for the ret, since
that will check that the call is in fact in tail position, which is a verifier
requirement for musttail.
https://reviews.llvm.org/D53586
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
