[PATCH] D53586: Implement Function Multiversioning for Non-ELF Systems.

Reid Kleckner via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 25 11:21:22 PDT 2018


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





More information about the cfe-commits mailing list