Commit Graph

11 Commits

Author SHA1 Message Date
Erich Keane 248ed07419 Make CPUDispatch resolver emit dependent functions.
Inline cpu_specific versions referenced before the cpu_dispatch function
weren't properly emitted, since they hadn't been referred to.  This
patch ensures that during resolver generation that all appropriate
versions are emitted.

Change-Id: I94c3766aaf9c75ca07a0ad8258efdbb834654ff8
llvm-svn: 348600
2018-12-07 15:31:23 +00:00
Erich Keane 05131ddfec Fix spelling of WINDOWS in a test
Change-Id: I232515655359f14308e1c5509c4b7db96d1fafcb
llvm-svn: 348598
2018-12-07 15:06:43 +00:00
Erich Keane c6d5631cd5 Revert "Multiversioning- Ensure all MV functions are emitted."
This reverts commit 65df29f9318ac13a633c0ce13b2b0bccf06e79ca.

AS suggested by @rsmith here: https://reviews.llvm.org/rL345839
I'm reverting this and solving the initial problem in a different way.

llvm-svn: 348595
2018-12-07 14:56:50 +00:00
Erich Keane 7304f0a66e Correct 'target' default behavior on redecl, allow forward declaration.
Declarations without the attribute were disallowed because it would be
ambiguous which 'target' it was supposed to be on.  For example:

void ___attribute__((target("v1"))) foo();
void foo(); // Redecl of above, or fwd decl of below?
void ___attribute__((target("v2"))) foo();

However, a first declaration doesn't have that problem, and erroring
prevents it from working in cases where the forward declaration is
useful.

Additionally, a forward declaration of target==default wouldn't properly
cause multiversioning, so this patch fixes that.

The patch was not split since the 'default' fix would require
implementing the same check for that case, followed by undoing the same
change for the fwd-decl implementation.

Change-Id: I66f2c5bc2477bcd3f7544b9c16c83ece257077b0
llvm-svn: 347805
2018-11-28 20:58:43 +00:00
Erich Keane f1005012c2 Multiversioning- Ensure all MV functions are emitted.
Multiverson function versions are always used (by the resolver), so ensure that
they are always emitted.

Change-Id: I5d2e0841fddf0d18918b3fb92ae76814add7ee96
llvm-svn: 345839
2018-11-01 15:11:43 +00:00
Erich Keane 19a8adc9bd Implement Function Multiversioning for Non-ELF Systems.
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 efficient as IFuncs of course, but is still quite
useful for large functions specifically developed for certain
processors.

This is unfortunately still limited to x86, since it depends on
__builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins.

The naming for the resolver/forwarding function for cpu-dispatch was
taken from ICC's implementation, which uses the unmodified name for this
(no mangling additions).  This is possible, since cpu-dispatch uses '.A'
for the 'default' version.

In 'target' multiversioning, this function keeps the '.resolver'
extension in order to keep the default function keeping the default
mangling.

Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284

Differential Revision: https://reviews.llvm.org/D53586

llvm-svn: 345298
2018-10-25 18:57:19 +00:00
Erich Keane 7ef210d053 Give Multiversion-inline functions linkonce linkage
Since multiversion variant functions can be inline, in C they become
available-externally linkage.  This ends up causing the variants to not
be emitted, and not available to the linker.

The solution is to make sure that multiversion functions are always
emitted by marking them linkonce.

Change-Id: I897aa37c7cbba0c1eb2c57ee881d5000a2113b75
llvm-svn: 344957
2018-10-22 21:20:45 +00:00
Craig Topper 9c8f3c9654 [X86] When checking the bits in cpu_features for function multiversioning dispatcher in the resolver, make sure all the required bits are set. Not just one of them
Summary:
The multiversioning code repurposed the code from __builtin_cpu_supports for checking if a single feature is enabled. That code essentially performed (_cpu_features & (1 << C)) != 0. But with the multiversioning path, the mask is no longer guaranteed to be a power of 2. So we return true anytime any one of the bits in the mask is set not just all of the bits.

The correct check is (_cpu_features & mask) == mask

Reviewers: erichkeane, echristo

Reviewed By: echristo

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D53460

llvm-svn: 344824
2018-10-20 01:30:00 +00:00
George Burgess IV 1913115204 [CodeGen] Fix a crash on mangling multiversioned functions
`multiVersionSortPriority` expects features to have no prefix. We
currently carry them around in the format "+${feature}".

llvm-svn: 322618
2018-01-17 04:46:04 +00:00
Erich Keane 0a6fde4895 Move target MV resolver to COMDAT
As reported here: https://bugs.llvm.org/show_bug.cgi?id=35921
The resolver functions should be in their own
COMDAT regions. This patch sets that up.

Differential Revision: https://reviews.llvm.org/D42110

llvm-svn: 322592
2018-01-16 19:49:52 +00:00
Erich Keane 281d20b601 Implement Attribute Target MultiVersioning
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.

This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.

Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.

The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.

Function templates and virtual functions are NOT yet supported (not supported
in GCC either).

Additionally, constructors/destructors are disallowed, but the former is 
planned.

llvm-svn: 322028
2018-01-08 21:34:17 +00:00