This revision was automatically updated to reflect the committed changes.
Closed by commit rL345298: Implement Function Multiversioning for Non-ELF
Systems. (authored by erichkeane, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D53586
erichkeane added a comment.
In https://reviews.llvm.org/D53586#1276198, @rnk wrote:
> 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 targ
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 O
erichkeane updated this revision to Diff 171118.
erichkeane added a comment.
ACTUALLY add the test this time :/ sorry about that!
https://reviews.llvm.org/D53586
Files:
include/clang/AST/Decl.h
include/clang/Basic/Attr.td
include/clang/Basic/TargetInfo.h
lib/AST/Decl.cpp
lib/Basic/Ta
erichkeane updated this revision to Diff 171088.
erichkeane marked an inline comment as done.
erichkeane added a comment.
Added test as requested by @rnk. How's it look? I hope I got the balance of
check-lines right.
https://reviews.llvm.org/D53586
Files:
include/clang/AST/Decl.h
include
rnk added inline comments.
Comment at: lib/CodeGen/CodeGenFunction.cpp:2395
+
+ llvm::CallInst *Result = Builder.CreateCall(FuncToReturn, Args);
+
rnk wrote:
> erichkeane wrote:
> > erichkeane wrote:
> > > rnk wrote:
> > > > This approach is... not going to work
echristo accepted this revision.
echristo added a comment.
This revision is now accepted and ready to land.
All of the target specific stuff looks fine to me. I'm going to defer to rnk
about the windows side of things and aaron for the attributes.
https://reviews.llvm.org/D53586
erichkeane updated this revision to Diff 170987.
erichkeane added a comment.
did everything suggested by @rnk as far as I know. Thanks again for the
reviews!
https://reviews.llvm.org/D53586
Files:
include/clang/AST/Decl.h
include/clang/Basic/Attr.td
include/clang/Basic/TargetInfo.h
li
rnk added inline comments.
Comment at: lib/CodeGen/CodeGenFunction.cpp:2391-2393
+ llvm::SmallVector Args;
+ llvm::for_each(Resolver->args(),
+ [&](llvm::Argument &Arg) { Args.push_back(&Arg); });
erichkeane wrote:
> rnk wrote:
> > Surely this w
erichkeane marked an inline comment as done.
erichkeane added a comment.
@rnk: I looked into the EmitMustTailThunk code, and don't terribly see what I'm
doing wrong. I clearly cannot CALL that function (since this works with
non-CXXMethodDecls), so I looked into using it. However, I saw that i
erichkeane marked 2 inline comments as done.
erichkeane added a comment.
In https://reviews.llvm.org/D53586#1273546, @rnk wrote:
> Seems reasonable. Should the resolver still be called `?foo@.resolver`, or
> should it get a new name, since it is quite functionally different now?
I'm not attach
rnk added a comment.
Seems reasonable. Should the resolver still be called `?foo@.resolver`, or
should it get a new name, since it is quite functionally different now?
Comment at: lib/CodeGen/CodeGenFunction.cpp:2381
+
+template
+static void CreateMultiVersionResolverReturn(ll
erichkeane created this revision.
erichkeane added reviewers: echristo, rnk, aaron.ballman.
erichkeane added a subscriber: mibintc.
Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the
resolver function directly to forward the call to the proper function.
This is not nearly as e
13 matches
Mail list logo
