Adding all libcall symbols to the link can have undesired consequences.
For example, the libgcc implementation of __sync_val_compare_and_swap_8
on 32-bit ARM pulls in an .init_array entry that aborts the program if
the Linux kernel does not support 64-bit atomics, which would prevent
the program from running even if it does not use 64-bit atomics.

This change makes it so that we only add libcall symbols to the
link before LTO if we have to, i.e. if the symbol's definition is in
bitcode. Any other required libcall symbols will be added to the link
after LTO when we add the LTO object file to the link.

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

llvm-svn: 339301

llvm-svn: 339300

isNegatibleForFree() should not matter here (as the test diffs show)
because it's always a win to replace an fsub+fadd with fneg. The
problem in D50195 persists because either (1) we are doing these
folds in the wrong order or (2) we're missing another fold for fadd.

llvm-svn: 339299

  
I don't know if it's possible to expose this diff in a test,
but we should always try simplifications (no new nodes created)
before more complicated transforms for efficiency (similar to
what we do in IR).

llvm-svn: 339298

Summary: Show the behavior of print operations in the ItaniumPartialDemangler. It's a summary of what the current integration in LLDB assumes. For new users this may be a useful example.

Reviewers: erik.pilkington

Subscribers: llvm-commits, lldb-commits

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

llvm-svn: 339297

llvm-svn: 339296

This addresses a FIXME that has existed since before clang supported the builtin.

This time with only reviewed changes.

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

llvm-svn: 339295

LLVM triple normalization is handling "unknown" and empty components
differently; for example given "x86_64-unknown-linux-gnu" and
"x86_64-linux-gnu" which should be equivalent, triple normalization
returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's
config.sub returns "x86_64-unknown-linux-gnu" for both
"x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the
triple normalization to behave the same way, replacing empty triple
components with "unknown".

This addresses PR37129.

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

llvm-svn: 339294

These are related to the block of code under review in D50195.

llvm-svn: 339293

Summary: It was not immediately clear to me whether or not non-null-terminated StringRef's are supported in ConstString and/or the counterpart mechanism. From this test it seems to be fine. Maybe useful to keep?

Reviewers: labath

Subscribers: lldb-commits

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

llvm-svn: 339292

Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.

In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function

Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.

The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```

It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.

The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.

Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.

One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).

First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.

Reviewers: labath, jingham, JDevlieghere, erik.pilkington

Subscribers: zturner, clayborg, mgorny, lldb-commits

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

llvm-svn: 339291

Profiling data show that Allocation::operator= is hot (see the data
attached to the Phab review).

Reorder a few fields within Allocation to avoid implicit structure
padding and shrink the structure. This should make copies a bit cheaper.

Also, given that an Allocation contains a std::vector (by way of
DataBufferHeap), it's preferable to make it move-only instead of
permitting expensive copies. As an added benefit this allows us to have
a single Allocation constructor instead of two.

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

llvm-svn: 339290

This add an additional unintended change in it.

llvm-svn: 339289

On Darwin we pin the DWARF line tables to version 2. Stop doing so for
DWARF v5 and later.

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

llvm-svn: 339288

This addresses a FIXME that has existed since before clang supported the builtin.

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

llvm-svn: 339287

Append LLVM_VERSION_SUFFIX to SOVERSION. This makes it possible
to use the suffix to differentiate binary-incompatible versions
of LLVM built via BUILD_SHARED_LIBS.

We are planning to use this to temporarily preserve ABI-incompatible
variants of LLVM while switching the system between them, e.g. when
rebuilding the system to use libc++. Normally this would mean that once
LLVM is rebuilt using libc++ all the reverse dependencies become
immediately broken. Using a distinct SOVERSION allows us to preserve
the ABI compatibility before all the packages are rebuilt.

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

llvm-svn: 339286

Store LLVM_VERSION_SUFFIX along with other version components
in LLVMConfig.cmake. This fixes preserving the suffix set while building
LLVM to stand-alone builds of other components, e.g. clang,
and therefore improves uniformity between the two build models.

Given that there is no apparent reason to omit this part of version,
that it is distributed to subprojects when building as part of LLVM
and that it is included in LLVM_PACKAGE_VERSION, I think it was omitted
accidentally rather than done on purpose.

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

llvm-svn: 339285

Summary:
These macros are defined in the C11 standard and can be defined based on
the __*_HAS_DENORM__ default macros.

Reviewers: bruno, rsmith, doug.gregor

Subscribers: llvm-commits, enh, srhines

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

llvm-svn: 339284

Normally, if any registers are spilled, we prefer to spill lr on Thumb1
so we can fold the "bx lr" into the "pop".  However, if there are tail
calls involved, restoring lr is expensive, so skip the optimization in
that case.

The spill of r7 in the new test also isn't necessary, but that's
mostly orthogonal to this patch. (It's the same code in
ARMFrameLowering, but it's not related to tail calls.)

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

llvm-svn: 339283

gcc defines an intrinsic called __builtin_clrsb which counts the number of extra sign bits on a number. This is equivalent to counting the number of leading zeros on a positive number or the number of leading ones on a negative number and subtracting one from the result. Since we can't count leading ones we need to invert negative numbers to count zeros.

This patch will cause the builtin to be expanded inline while gcc uses a call to a function like clrsbdi2 that is implemented in libgcc. But this is similar to what we already do for popcnt. And I don't think compiler-rt supports clrsbdi2.

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

llvm-svn: 339282

r330571 added a new FrontendTimesIsEnabled variable and replaced many usages of llvm::TimePassesIsEnabled. Including the place that set llvm::TimePassesIsEnabled for -ftime-report. The effect of this is that -ftime-report now only contains the timers specifically referenced in CodeGenAction.cpp and none of the timers in the backend.

This commit adds back the assignment, but otherwise leaves everything else unchanged.

llvm-svn: 339281

llvm-svn: 339280

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

llvm-svn: 339279

Fast FMAF is not a sufficient condition to enable denormals.
Before VI, enabling denormals caused F32 instructions to
run at F64 speeds.

llvm-svn: 339278

The support for macOS 10.4 has been dropped by Xcode 10.

rdar://42876880

llvm-svn: 339277

llvm-svn: 339276

Template manglings use a fresh back-referencing context, so we
need to do the same.  This fixes several existing tests which are
marked as FIXME, so those are now actually run.

llvm-svn: 339275

llvm-svn: 339274

Test tail padded automatic variable at different width, because they encounter different codegen.

llvm-svn: 339273

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

llvm-svn: 339272

I think this is the only situation where the callsite
will have a null instruction.

llvm-svn: 339271

llvm-svn: 339270

When reading a custom WASM section, it was possible that its name
extended beyond the size of the section. This resulted in a bogus value
for the section size due to the size overflowing.

Fixes heap buffer overflow detected by OSS-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8190

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

llvm-svn: 339269

When using APPLE extensions, don't duplicate the compiler invocation's
flags both in AT_producer and AT_APPLE_flags.

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

llvm-svn: 339268

This is a sibling to the simplify from:
https://reviews.llvm.org/rL339174

llvm-svn: 339267

This is a sibling to the simplify from:
rL339171

llvm-svn: 339266

NFC refactor of code to generate debug info for OpenCL 2.X blocks.

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

llvm-svn: 339265

As suggested by @theraven on PR38210, this patch fixes the gcc -Woverloaded-virtual warnings by renaming the extra CGObjCGNU::GetSelector method to CGObjCGNU::GetTypedSelector

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

llvm-svn: 339264

The scalar cases are handled in instcombine's internal
reassociation pass for FP ops, but it misses the vector types.

These patterns are similar to what was handled in InstSimplify in:
https://reviews.llvm.org/rL339171
https://reviews.llvm.org/rL339174
https://reviews.llvm.org/rL339176
...but we can't use instsimplify on these because we require negation
of the original operand.

llvm-svn: 339263

The isConstOrConstSplat result is only used in a ISD::matchUnaryPredicate call which can perform the equivalent iteration just as quickly.

llvm-svn: 339262