Apparently I failed to make this work when I fixed it in the disassembler way back in r224862.

llvm-svn: 319611

lldb fails to build standalone on x86

-- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed
CMake Error at CheckAtomic.cmake:66 (check_library_exists):
  Unknown CMake command "check_library_exists".
Call Stack (most recent call first):
  LLDBStandalone.cmake:90 (include)
CMakeLists.txt:3 (include)

Reviewed By: rnk

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

llvm-svn: 319610

Reviewers: petecoup, kparzysz

Reviewed By: petecoup

Subscribers: llvm-commits

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

llvm-svn: 319609

llvm-svn: 319608

Disable post-legalization store for AArch64 backend which is causing
errors out-of-tree.

llvm-svn: 319607

Without specifying the signedness of the underlying type for Action,
packing it in a 1-bit field may restrict its range to [-1, 0] which
can't represent Match.

llvm-svn: 319606

whether they have an initializer.

We cannot distinguish between a declaration of a variable template
specialization and a definition of one that lacks an initializer without this,
and would previously mistake the latter for the former.

llvm-svn: 319605

llvm-svn: 319604

r319488 reportedly broke one of LLVM bots (ubuntu-gcc7.1-werror), and this patch
depends on that patch.
See http://lab.llvm.org:8011/builders/ubuntu-gcc7.1-werror/builds/3369 for
details.

llvm-svn: 319603

This patch reportedly broke one of LLVM bots (ubuntu-gcc7.1-werror).

See http://lab.llvm.org:8011/builders/ubuntu-gcc7.1-werror/builds/3369 for
details.

llvm-svn: 319602

llvm-svn: 319601

This change actually makes the linker slightly faster. My observation
is that, with this patch, link time of clang without debug is about 1%
faster.

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

llvm-svn: 319600

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

llvm-svn: 319599

LLDB.framework gets loaded into Xcode and other 
frameworks, and this is inserting a signal handler into
the process even when lldb isn't used.  I have a bunch
of reports of this SignalHandler blowing out the stack,
which renders crash reports for the crash useless.

And in any case libraries really shouldn't be installing
signal handlers.

I only turned this off for APPLE platforms, I'll let
the maintainers of other platforms decide what policy
they want to have w.r.t. this.

llvm-svn: 319598

llvm-svn: 319597

These asserts are no-ops, and are supplanted by -Wcovered-switch.

llvm-svn: 319596

llvm-svn: 319595

llvm-svn: 319594

There are 20 LLVM math intrinsics that correspond to mathlib calls according to the LangRef:
http://llvm.org/docs/LangRef.html#standard-c-library-intrinsics

We were only converting 3 mathlib calls (sqrt, fma, pow) and 12 builtin calls (ceil, copysign, 
fabs, floor, fma, fmax, fmin, nearbyint, pow, rint, round, trunc) to their intrinsic-equivalents.

This patch pulls the transforms together and handles all 20 cases. The switch is guarded by a 
check for const-ness to make sure we're not doing the transform if errno could possibly be set by
the libcall or builtin.

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

llvm-svn: 319593

Patch by Nicholas Wilson

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

llvm-svn: 319592

This reverts r319543, due to ASan bot breakage.

llvm-svn: 319591

llvm-svn: 319590

llvm-svn: 319589

Currently, the outliner considers candidates that intersect with themselves in
the candidate pruning step. That is, candidates of the form "AA" in ranges like
"AAAAAA". In that range, it looks like there are 5 instances of "AA" that could
possibly be outlined, and that's considered in the benefit calculation.

However, only at most 3 instances of "AA" could ever be outlined in "AAAAAA".
Thus, it's possible to pass through "AA" to the candidate selection step even
though it's *never* the case that "AA" could be outlined. This makes it so that
when we find candidates, we consider only non-overlapping occurrences of that
candidate.

llvm-svn: 319588

due to failures in AArch and ARM code gen.

llvm-svn: 319587

r230670 introduced a step to map EH register numbers to standard
DWARF register numbers. This failed to consider the case when a
user .cfi_* directive uses an integer literal rather than a
register name, to specify a DWARF register number that has no
corresponding LLVM register number (e.g. a special register that
the compiler and assembler have no name for).

Fixes PR34028.

Patch by Roland McGrath

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

llvm-svn: 319586

Previously we emitted `__tgt_target_teams` only for standalone teams
directives. This patch allows emit this function for all teams-based
directives.

llvm-svn: 319585

of its argument, perform function-to-pointer and array-to-pointer decay on the
parameter type first.

Otherwise deduction will fail, as the type of the argument will be decayed.

llvm-svn: 319584

Turns out we can have comparisons which are indirect users of the induction variable that we can make invariant.  In this case, there is no loop invariant value contributing and we'd fail an assert.

The test case was found by a java fuzzer and reduced.  It's a real cornercase.  You have to have a static loop which we've already proven only executes once, but haven't broken the backedge on, and an inner phi whose result can be constant folded by SCEV using exit count reasoning but not proven by isKnownPredicate.  To my knowledge, only the fuzzer has hit this case.

llvm-svn: 319583

Still fails for some bots.

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

llvm-svn: 319582

These are blocks that haven't not been executed during training.  For large
projects this could make a significant difference.  For the project, I was
looking at, I got an order of magnitude decrease in the size of the total YAML
files with this and r319235.

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

Re-commit after fixing the failing testcase in rL319576, rL319577 and
rL319578.

llvm-svn: 319581

I have found LLDB commonly looks up lldb::user_id_t 0xffffffff failing to find
its DIE. One would rather expect LLDB_INVALID_UID == 0xffffffffffffffff in such
case.

DWARFASTParserClang.cpp:495
492             type_sp.reset(
493                 new Type(die.GetID(), dwarf, type_name_const_str, byte_size, NULL,
494                          DIERef(encoding_uid).GetUID(dwarf), encoding_data_type,
495                          &decl, clang_type, resolve_state));
encoding_uid = (DWARFFormValue) {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}}
-> DIERef::DIERef(const DWARFFormValue &form_value = {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}})
-> (DIERef) {cu_offset = 0xffffffff, die_offset = 0xffffffff}
-> lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf = 0x61d00000b480) const
-> Type::Type(lldb::user_id_t encoding_uid = 0xffffffff)
But 0xffffffff !=
#define LLDB_INVALID_UID UINT64_MAX

Differential revision: https://reviews.llvm.org/D37492

llvm-svn: 319580

llvm-svn: 319579

The driver-based test is still not identical to the front-end line, remove the
hotness threshold from there and add a new front-end based test with
threshold.

llvm-svn: 319578

1. Require hotness on all remark lines with -verify.

3. Fix the samplePGO file to actually produce hotness on each line.

The second remark has hotness 60 rather 30 which I don't quite understand but
testing this is strictly better than before.  It also unblocks the commit of
D40678.

llvm-svn: 319577

A RUN line was referring to the previous RUN line but a new test was added in
between them.  Just reorder the lines.

Note this still does not completely fix this the brokenness of the comment as
the driver-based test gained a new hotness-threshold argument in r306948 but
I'll fix that is a separate commit.

llvm-svn: 319576

Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.

This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.

I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.

Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.

Please review carefully, i have not worked with lit/sanitizer tests before.

The original attempt, r319525 was reverted in r319526 due
to the failures in compiler-rt standalone builds.

Reviewers: eugenis, vitalybuka

Reviewed By: eugenis

Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc

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

llvm-svn: 319575

Only pass Native to LLVM_TARGETS_TO_BUILD.

Summary:
Remove the redundant, config-time call to cmake when
building host tools for cross compiles or optimized tablegen..

The config-time call to cmake is redundant because it will always get
called again when the CONFIGURE_LLVM_${target_name} target fires at
build-time.  This speeds up initial configuration, but has no affect
on build behavior.

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

llvm-svn: 319574

Followup to D39595. Removes a bunch of redundant checks.

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

llvm-svn: 319573

llvm-svn: 319572