`__declspec(dllexport)` and `__declspec(dllimport)` should only be used
when building libc++abi as a DLL, but that's the more common use case,
so default to adding the annotations and add an option to opt out.
Similar to r282449, which made the corresponding change for libc++.
Differential Revision: https://reviews.llvm.org/D24945
llvm-svn: 282470
Summary:
We don't currently need this facility for CFI. Disabling individual hot methods proved
to be a better strategy in Chrome.
Also, the design of the feature is suboptimal, as pointed out by Peter Collingbourne.
Reviewers: pcc
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D24948
llvm-svn: 282461
So that it is clear that FileOutputBuffer does not depend on
PDB file builder. Eventually we will have to to get the file size
info from the file builder to create a file with the exact size.
NFC.
llvm-svn: 282454
- This is primarily useful as a "fail fast" mode for lit, where it will stop
running tests after the first failure.
- Patch by Max Moiseev.
llvm-svn: 282452
builds.
On Windows the __declspec(dllimport) and __declspec(dllexport) attributes
require linking to a DLL, not a static library. Previously these annotations
were disabled by default unless _LIBCPP_DLL was defined. However the DLL
configuration is probably the more common one, so it should be supported by
default.
This patch enables import/export attributes by default and adds a
_LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this
behavior. If libc++ is built as a static library on Windows then a custom __config
header will be generated that predefines this macro.
This patch is based off work by Shoaib Meenai.
llvm-svn: 282449
Fixes the following:
BOOL (^aaa)(void) = ^BOOL {
};
The first BOOL's token was getting set to TT_FunctionAnnotationRParen
incorrectly, which was causing an unexpected newline after (^aaa). This
was introduced in r245846.
Patch by Kent Sutherland, thank you!
llvm-svn: 282448
On ARM, there are multiple versions of each of the intrinsics, with
acquire/relaxed/release barrier semantics.
The newly added ones are provided as inline functions here instead of builtins,
since they should only be available on certain archs (arm/aarch64).
This is necessary in order to compile C++ code for ARM in MSVC mode.
Patch by Martin Storsjö!
llvm-svn: 282447
Summary: This patch fixes a couple of typos that cause compilation errors when application includes <unordered_map> and enables the libc++'s debugging capabilities.
Reviewers: EricWF
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24883
llvm-svn: 282446
When we have dynamic allocas we have a frame pointer, and
when we're lowering frame indexes we should make sure we use it.
Patch by Jacob Gravelle
Differential Revision: https://reviews.llvm.org/D24889
llvm-svn: 282442
other load commands that use the Mach::linkedit_data_command type
but not used in llvm libObject code but used in llvm tool code.
This includes LC_FUNCTION_STARTS, LC_SEGMENT_SPLIT_INFO
and LC_DYLIB_CODE_SIGN_DRS load commands.
llvm-svn: 282441
Summary:
`std::move` and `std::forward` were not marked constexpr in C++11. This can be very damaging because it makes otherwise constant expressions non-constant. For example:
```
#include <utility>
template <class T>
struct Foo {
constexpr Foo(T&& tx) : t(std::move(tx)) {}
T t;
};
[[clang::require_constant_initialization]] Foo<int> f(42); // Foo should be constant initialized but C++11 move is not constexpr. As a result `f` is an unsafe global.
```
This patch applies `constexpr` to `move` and `forward` as an extension in C++11. Normally the library is not allowed to add `constexpr` because it may be observable to the user. In particular adding constexpr may cause valid code to stop compiling. However these problems only happen in more complex situations, like making `__invoke(...)` constexpr. `forward` and `move` are simply enough that applying `constexpr` is safe.
Note that libstdc++ has offered this extension since at least 4.8.1.
Most of the changes in this patch are simply test cleanups or additions. The main changes in the tests are:
* Fold all `forward_N.fail.cpp` tests into a single `forward.fail.cpp` test using -verify.
* Delete most `move_only_N.fail.cpp` tests because they weren't actually testing anything.
* Fold `move_copy.pass.cpp` and `move_only.pass.cpp` into a single `move.pass.cpp` test.
* Add return type and noexcept tests for `forward` and `move`.
Reviewers: rsmith, mclow.lists, EricWF
Subscribers: K-ballo, loladiro
Differential Revision: https://reviews.llvm.org/D24637
llvm-svn: 282439
Summary:
This patch improves thinlto importer
by importing 3x larger functions that are called from hot block.
I compared performance with the trunk on spec, and there
were about 2% on povray and 3.33% on milc. These results seems
to be consistant and match the results Teresa got with her simple
heuristic. Some benchmarks got slower but I think they are just
noisy (mcf, xalancbmki, omnetpp)- running the benchmarks again with
more iterations to confirm. Geomean of all benchmarks including the noisy ones
were about +0.02%.
I see much better improvement on google branch with Easwaran patch
for pgo callsite inlining (the inliner actually inline those big functions)
Over all I see +0.5% improvement, and I get +8.65% on povray.
So I guess we will see much bigger change when Easwaran patch will land
(it depends on new pass manager), but it is still worth putting this to trunk
before it.
Implementation details changes:
- Removed CallsiteCount.
- ProfileCount got replaced by Hotness
- hot-import-multiplier is set to 3.0 for now,
didn't have time to tune it up, but I see that we get most of the interesting
functions with 3, so there is no much performance difference with higher, and
binary size doesn't grow as much as with 10.0.
Reviewers: eraman, mehdi_amini, tejohnson
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D24638
llvm-svn: 282437
This is the Linux counterpart to the sampling support I added
on the macOS side.
This change also introduces zip-file compression if the size of
the sample output is greater than 10 KB. The Linux side can be
quite large and the textual content is averaging over a 10x
compression factor on tests that I force to time out. When
compression takes place, the filename becomes:
{session_dir}/{TestFilename.py}-{pid}.sample.zip
This support relies on the linux 'perf' tool. If it isn't
present, the behavior is to ignore pre-kill processing of
the timed out test process.
Note calling the perf tool under the timeout command appears
to nuke the profiled process. This was causing the timeout
kill logic to fail due to the process having disappeared.
I modified the kill logic to catch the case of the process
not existing, and I have it ignore the kill request in that
case. Any other exception is still raised.
Reviewers: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24890
llvm-svn: 282436
Declare __STDC_FORMAT_MACROS, __STDC_LIMIT_MACROS and
__STDC_CONSTANT_MACROS before including real inttypes.h/stdint.h when
the wrapper-header is included in C++11, in order to enable
the necessary macros in C99-compliant libc.
The C99 standard defined that the format macros in inttypes.h should be
defined by the C++ implementations only when __STDC_FORMAT_MACROS is
defined, and the limit and constant macros in stdint.h should be defined
only when __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS are defined
appropriately. Following this specification, multiple old versions of
glibc up to 2.17 do not define those macros by default for C++,
rendering the libc++ headers non-compliant to the C++11 standard.
In order to achieve the necessary compliance, __STDC_FORMAT_MACROS is
defined in wrapped inttypes.h just before including the system
inttypes.h, when C++11 or newer is used. Both __STDC_LIMIT_MACROS
and __STDC_CONSTANT_MACROS are defined in newly-wrapped stdint.h. This
fixes the C++11 compliance while preserving the current behavior for
C++03.
Differential Revision: https://reviews.llvm.org/D24903
llvm-svn: 282435
This allows debugging of the JIT and other analyses of the internals of the
expression parser. I've also added a testcase that verifies that the setting
works correctly when off and on.
llvm-svn: 282434
CommandData breakpoint commands didn't know whether they were
Python or Command line commands, so they couldn't serialize &
deserialize themselves properly. Fix that.
I also changed the "breakpoint list" command to note in the output
when the commands are Python commands. Fortunately only one test
was relying on this explicit bit of text output.
llvm-svn: 282432
The BYTE, SHORT, LONG, and QUAD commands store one, two, four, and eight bytes (respectively).
After storing the bytes, the location counter is incremented by the number of bytes
stored.
Previously our scripts handles these commands incorrectly. For example:
SECTIONS {
.foo : {
*(.foo.1)
BYTE(0x11)
...
We accepted the script above treating BYTE as input section description.
These commands are used in the wild though.
Differential revision: https://reviews.llvm.org/D24830
llvm-svn: 282429
PR30521 was about linking shared library. After r282295 code when linking -shared produced
"entry symbol not found" warning, what in combination with --fatal-errors failed linkage.
Patch fixes logic (and adds testcases) to follow next rules:
1) If entry was specified and not found report warning.
2) If entry was not specified then:
a) Emit warning if not -shared.
b) Do not emit warning if -shared.
Differential revision: https://reviews.llvm.org/D24913
llvm-svn: 282427
This option behaves in a similar spirit as -save-temps and writes
internal llvm statistics in json format to a file.
Differential Revision: https://reviews.llvm.org/D24820
llvm-svn: 282426
Previously enabling the statistics with EnableStatistics() would lead to
them getting printed to stderr/-info-output-file on exit. However
frontends may want a way to enable statistics and do the printing on
their own instead of the forced printing on exit.
This changes the code so that only the -stats option enables printing on
exit, EnableStatistics() only enables the tracking but requires invoking
one of the PrintStatistics() variants.
Differential Revision: https://reviews.llvm.org/D24819
llvm-svn: 282425
Rework getLongestCommonPrefixLen() so that it doesn't access string null
terminators. The old version with std::mismatch would do this:
|
v
Strings[0] = ['a', nil]
Strings[1] = ['a', 'a', nil]
^
|
This should silence a warning from the MSVC runtime (PR30515). As
before, I tested this out by preparing a coverage report for FileCheck.
Thanks to Yaron Keren for the report!
llvm-svn: 282422
Craig Topper