Almost all these changes are conditioned and only apply to the new
x86-64 f128 type configuration, which will be enabled in a follow up
patch. They are required together to make new f128 work. If there is
any error, we should fix or revert them as a whole.
These changes should have no impact to current configurations.
* Relax type legalization checks to accept new f128 type configuration,
whose TypeAction is TypeSoftenFloat, not TypeLegal, but also has
TLI.isTypeLegal true.
* Relax GetSoftenedFloat to return in some cases f128 type SDValue,
which is TLI.isTypeLegal but not "softened" to i128 node.
* Allow customized FABS, FNEG, FCOPYSIGN on new f128 type configuration,
to generate optimized bitwise operators for libm functions.
* Enhance related Lower* functions to handle f128 type.
* Enhance DAGTypeLegalizer::run, SoftenFloatResult, and related functions
to keep new f128 type in register, and convert f128 operators to library calls.
* Fix Combiner, Emitter, Legalizer routines that did not handle f128 type.
* Add ExpandConstant to handle i128 constants, ExpandNode
to handle ISD::Constant node.
* Add one more parameter to getCommonSubClass and firstCommonClass,
to guarantee that returned common sub class will contain the specified
simple value type.
This extra parameter is used by EmitCopyFromReg in InstrEmitter.cpp.
* Fix infinite loop in getTypeLegalizationCost when f128 is the value type.
* Fix printOperand to handle null operand.
* Enhance ISD::BITCAST node to handle f128 constant.
* Expand new f128 type for BR_CC, SELECT_CC, SELECT, SETCC nodes.
* Enhance X86AsmPrinter to emit f128 values in comments.
Differential Revision: http://reviews.llvm.org/D15134
llvm-svn: 254653
DenseMap is most applicable when both keys and values are small.
In this case, the value violates that assumption, causing quite
significant memory overhead. A std::unordered_map is more appropriate
in this case (or at least fixed the memory problems I was seeing).
Differential Revision: http://reviews.llvm.org/D14910
llvm-svn: 254651
The tests were failing because the types of some member functions, when
printed, unexpectedly had "__attribute__((thiscall))" at the end. The
types in question were relatively unimportant to begin with, so they
were removed/replaced with regexes.
llvm-svn: 254650
This provides interface to get and set maximum function counts to Module. This
would allow things like determination of function hotness. The actual setting
of this max function count will have to be done in the frontend.
Differential Revision: http://reviews.llvm.org/D15003
llvm-svn: 254647
The introduction of pass_object_size fixed a few bugs related to taking
the address of a function with enable_if attributes. This patch adds
tests for the cases that were fixed.
llvm-svn: 254646
Summary:
These ADJCALLSTACK markers don't generate code, but they keep dynamic
alloca code that calls chkstk out of the prologue.
This slightly pessimizes inalloca calls by preventing some register copy
coalescing, but I can live with that.
Reviewers: qcolombet
Subscribers: hans, llvm-commits
Differential Revision: http://reviews.llvm.org/D15200
llvm-svn: 254645
* Adds COMPILER_RT_EXTERNALIZE_DEBUGINFO option
* On Darwin this results in calling dsymutil and strip after linking
* This generates an error on non-darwin platforms, matching the LLVM behavior
llvm-svn: 254643
Don't warn about addresses of stack-allocated blocks escaping if the block
region was cast with CK_CopyAndAutoreleaseBlockObject. These casts, which
are introduced in the implicit conversion operator for lambda-to-block
conversions, cause the block to be copied to the heap -- so the warning is
spurious.
llvm-svn: 254639
These additions were meant to go in as a part of r254554; while it's
certainly nice to have new functionality, it's nicer if we have tests to
go with it. :)
llvm-svn: 254632
This is just a build dependency optimization. Running check-libcxx will still build libcxx and function as expected, it just removes libcxx from the all build and install targets.
llvm-svn: 254628
Summary: This adds support for generating dSYM files and stripping debug info from executables and dylibs. It also supports passing -object_path_lto to the linker to generate dSYMs for LTO builds.
Reviewers: bogner, friss
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15133
llvm-svn: 254627
Summary:
Fix import from module with appending var, which cannot be imported. The
first fix is to remove an overly-aggressive error check.
The second fix is to deal with restructuring introduced to the module
linker yesterday in r254418 (actually, this fix was included already
in r254559, just added some additional cleanup).
Test by Mehdi Amini.
Reviewers: joker.eph, rafael
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D15156
llvm-svn: 254624
After, properties from class extensions no longer show up in
ObjCInterfaceDecl::properties(). Make ObjCCommonMac::EmitPropertyList()
explicitly look for properties in class extensions before looking at
direct properties.
Also add a test that passes both with clang before r251874 and after this
patch (but fails with r251874 and without this patch).
llvm-svn: 254622
In the case of a conditional branch without a preceding cmp we used to emit
a "and; cmp; b.eq/b.ne" sequence, use tbz/tbnz instead.
Differential Revision: http://reviews.llvm.org/D15122
llvm-svn: 254621
`MaybeReexec` contains a 1024-byte long local array, which produces a warning about frame size:
.../lib/sanitizer_common/sanitizer_mac.cc:548:6: warning: stack frame size of 1132 bytes in function '__sanitizer::MaybeReexec' [-Wframe-larger-than=]
Let's replace it with InternalScopedString.
Differential Revision: http://reviews.llvm.org/D15181
llvm-svn: 254619
For OS X builds of compiler-rt, we run `darwin_test_archs` to determine which architectures can the toolchain target. This detection takes quite a long time, and the result is always the same (as long as you don't upgrade your OS, system headers or toolchain). Let's cache the result.
Differential Revision: http://reviews.llvm.org/D15179
llvm-svn: 254618
r249143 added test/Driver/darwin-ld-lto.c which requires libLTO.dylib
to pass, but when running `ninja check-clang` in a fresh build directory
nothing caused libLTO.dylib to be built and the test would fail.
llvm-svn: 254612
On OS X, there are other-than-pthread locking APIs that are used quite extensively - OSSpinLock and os_lock_lock. Let's add interceptors for those.
Differential Revision: http://reviews.llvm.org/D14987
llvm-svn: 254611
The code was duplicated to handle the custom symbol name for functions
in libdl.so for android. This change modify the way we handle the issue
to eliminate a lot of duplicated code.
Differential revision: http://reviews.llvm.org/D15183
llvm-svn: 254608
Currently "<type> ptr <reg name>" treated as <reg name> in MS inline asm, ignoring the "<type> ptr" completely and possibly ignoring the intention of the user.
Fixed llvm to produce an error when encountering "<type> ptr <reg name>" operands.
For example: andpd xmm1,xmmword ptr xmm1 --> andpd xmm1, xmm1
though andpd has 2 possible matching formats - andpd xmm, xmm/m128
Patch by: ziv.izhar@intel.com
Differential Revision: http://reviews.llvm.org/D14607
llvm-svn: 254607
This reverts commit r254143 which introduces a crash on the following input:
f(char *);
g(char *);
#pragma weak f = g
int g(char *p) {}
llvm-svn: 254605
Matthias Braun