llvm-svn: 370352

llvm-svn: 370346

llvm-svn: 370344

llvm-svn: 370342

llvm-svn: 370318

------------------------------------------------------------------------
r369184 | maskray | 2019-08-17 08:28:03 +0200 (Sat, 17 Aug 2019) | 9 lines

[ELF][PPC] Fix getRelExpr for R_PPC64_REL16_HI

Fixes https://github.com/ClangBuiltLinux/linux/issues/640

R_PPC64_REL16_HI was incorrectly computed as an R_ABS relocation.
rLLD368964 made it a linker failure. Change it to use R_PC to fix the
failures.

Add ppc64-reloc-rel.s for these R_PPC64_REL* tests.
------------------------------------------------------------------------

llvm-svn: 370313

------------------------------------------------------------------------
r368964 | maskray | 2019-08-15 07:22:23 +0200 (Thu, 15 Aug 2019) | 11 lines

[ELF][PPC] Improve error message for unknown relocations

Like rLLD354040.

Previously, for unrecognized relocation types, in -no-pie mode:

  foo.o: unrecognized reloc 256

In -pie/-shared mode:

  error: can't create dynamic relocation R_PPC_xxx against symbol: yyy in readonly segment
------------------------------------------------------------------------

llvm-svn: 370312

------------------------------------------------------------------------
r370271 | tstellar | 2019-08-29 00:59:04 +0200 (Thu, 29 Aug 2019) | 6 lines

[LLVM-C] Fix omission of INSTALL_WITH_TOOLCHAIN to llvm_add_library()

Due to a misstake with r365902 that tried to simplify the install with
toolchain logic LLVM-C.dll was no longer being installed.

Patch By: Jakob Bornecrantz
------------------------------------------------------------------------

llvm-svn: 370306

------------------------------------------------------------------------
r370035 | devnexen | 2019-08-27 12:04:03 +0200 (Tue, 27 Aug 2019) | 7 lines

[ReleaseNotes] MemorySanitizer support of ASLR on FreeBSD

Reviewers: sylvestre.ledru, kcc

Reviewed By: sylvestre.ledru

Differential Revision: https://reviews.llvm.org/D66792
------------------------------------------------------------------------

llvm-svn: 370213

------------------------------------------------------------------------
r370204 | hans | 2019-08-28 15:55:10 +0200 (Wed, 28 Aug 2019) | 6 lines

[SelectionDAG] Don't generate libcalls for wide shifts on Windows (PR42711)

Neither libgcc or compiler-rt are usually used on Windows, so these
functions can't be called.

Differential revision: https://reviews.llvm.org/D66880
------------------------------------------------------------------------

llvm-svn: 370205

------------------------------------------------------------------------
r369886 | bjope | 2019-08-26 11:29:53 +0200 (Mon, 26 Aug 2019) | 23 lines

[LoopUnroll] Handle certain PHIs in full unrolling properly

Summary:
When reconstructing the CFG of the loop after unrolling,
LoopUnroll could in some cases remove the phi operands of
loop-carried values instead of preserving them, resulting
in undef phi values after loop unrolling.

When doing this reconstruction, avoid removing incoming
phi values for phis in the successor blocks if the successor
is the block we are jumping to anyway.

Patch-by: ebevhan

Reviewers: fhahn, efriedma

Reviewed By: fhahn

Subscribers: bjope, lebedev.ri, zzheng, dmgreen, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D66334
------------------------------------------------------------------------

llvm-svn: 370182

------------------------------------------------------------------------
r370073 | lenary | 2019-08-27 17:41:16 +0200 (Tue, 27 Aug 2019) | 13 lines

[RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

Summary: This ensures that libcalls aren't generated when the target supports atomics. Atomics aren't in the base RV32I/RV64I instruction sets, so MaxAtomicInlineWidth and MaxAtomicPromoteWidth are set only when the atomics extension is being targeted. This must be done in setMaxAtomicWidth, as this should be done after handleTargetFeatures has been called.

Reviewers: jfb, jyknight, wmi, asb

Reviewed By: asb

Subscribers: pzheng, MaskRay, s.egerton, lenary, dexonsmith, psnobl, benna, Jim, JohnLLVM, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, lewis-revill, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D57450
------------------------------------------------------------------------

llvm-svn: 370181

------------------------------------------------------------------------
r370176 | hans | 2019-08-28 11:21:56 +0200 (Wed, 28 Aug 2019) | 15 lines

[LLVM-C] Fix ByVal Attribute crashing

With the introduction of the typed byval attribute change there was no
way that the LLVM-C API could create the correct class Attribute. If a
program that uses the C API creates a ByVal attribute and annotates a
function with that attribute LLVM will crash when it assembles or write
that module containing the function out as bitcode.

This change is a minimal fix to at least allow code to work, this is
because the byval change is on the 9.0 and I don't want to introduce new
LLVM-C API this late in the release cycle.

By Jakob Bornecrantz!

Differential revision: https://reviews.llvm.org/D66144
------------------------------------------------------------------------

llvm-svn: 370178

llvm-svn: 370167

By Kristóf Umann!

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

llvm-svn: 370166

llvm-svn: 370077

By Alex Bradbury!

llvm-svn: 370076

By Lei Huang!

llvm-svn: 370065

------------------------------------------------------------------------
r370036 | tnorthover | 2019-08-27 12:21:11 +0200 (Tue, 27 Aug 2019) | 8 lines

AArch64: avoid creating cycle in DAG for post-increment NEON ops.

Inserting a value into Visited has the effect of terminating a search for
predecessors if that node is seen. This is legitimate for the base address, and
acts as a slight performance optimization, but the vector-building node can be
paert of a legitimate cycle so we shouldn't stop searching there.

PR43056.
------------------------------------------------------------------------

llvm-svn: 370063

------------------------------------------------------------------------
r369834 | rsmith | 2019-08-24 04:30:00 +0200 (Sat, 24 Aug 2019) | 8 lines

PR42513: Enter the proper DeclContext before substituting into an
default template argument expression.

We already did this for type template parameters and template template
parameters, but apparently forgot to do so for non-type template
parameters. This causes the substituted default argument expression to
be substituted in the proper context, and in particular to properly mark
its subexpressions as odr-used.
------------------------------------------------------------------------

llvm-svn: 370038

------------------------------------------------------------------------
r369749 | stulova | 2019-08-23 13:43:49 +0200 (Fri, 23 Aug 2019) | 5 lines

[Docs][OpenCL] Several corrections to C++ for OpenCL

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


------------------------------------------------------------------------

llvm-svn: 370031

llvm-svn: 370024

------------------------------------------------------------------------
r369829 | rsmith | 2019-08-24 03:23:57 +0200 (Sat, 24 Aug 2019) | 3 lines

PR40674: fix assertion failure if a structured binding declaration has a
tuple-like decomposition that produces value-dependent reference
bindings.
------------------------------------------------------------------------

llvm-svn: 369921

llvm-svn: 369913

From Kristof!

llvm-svn: 369912

------------------------------------------------------------------------
r367115 | jdevlieghere | 2019-07-26 16:26:33 +0200 (Fri, 26 Jul 2019) | 6 lines

[CMake] Loosen Python version check and ignore patch version

Some versions of macOS report a different patch version for the system
provided interpreter and libraries.

Differential revision: https://reviews.llvm.org/D65230
------------------------------------------------------------------------

------------------------------------------------------------------------
r367125 | jdevlieghere | 2019-07-26 18:15:19 +0200 (Fri, 26 Jul 2019) | 3 lines

[CMake] Print Python version on Windows

Trying to figure out what's causing the Windows bot to fail.
------------------------------------------------------------------------

------------------------------------------------------------------------
r367127 | jdevlieghere | 2019-07-26 18:32:49 +0200 (Fri, 26 Jul 2019) | 4 lines

[CMake] Fix find_python_libs_windows

Exporting PYTHON_INCLUDE_DIR to the Python scope somehow got lost in my
last change. Add it back again. This should fix the Windows bot!
------------------------------------------------------------------------

------------------------------------------------------------------------
r367153 | jdevlieghere | 2019-07-26 22:58:10 +0200 (Fri, 26 Jul 2019) | 5 lines

[CMake] Print the correct variables

This didn't get updated after we decided to set PYTHON_MAJOR_VERSION and
PYTHON_MINOR_VERSION in find_python_libs_windows, instead of parsing the
variables ourselves.
------------------------------------------------------------------------

llvm-svn: 369903

------------------------------------------------------------------------
r366447 | jdevlieghere | 2019-07-18 17:17:42 +0200 (Thu, 18 Jul 2019) | 19 lines

[CMake] Don't set Python_ADDITIONAL_VERSIONS

Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.

However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.

Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.

This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.

Differential revision: https://reviews.llvm.org/D64894
------------------------------------------------------------------------

llvm-svn: 369902

------------------------------------------------------------------------
r366447 | jdevlieghere | 2019-07-18 17:17:42 +0200 (Thu, 18 Jul 2019) | 19 lines

[CMake] Don't set Python_ADDITIONAL_VERSIONS

Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.

However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.

Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.

This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.

Differential revision: https://reviews.llvm.org/D64894
------------------------------------------------------------------------

llvm-svn: 369901

------------------------------------------------------------------------
r366447 | jdevlieghere | 2019-07-18 17:17:42 +0200 (Thu, 18 Jul 2019) | 19 lines

[CMake] Don't set Python_ADDITIONAL_VERSIONS

Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.

However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.

Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.

This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.

Differential revision: https://reviews.llvm.org/D64894
------------------------------------------------------------------------

llvm-svn: 369900

------------------------------------------------------------------------
r366447 | jdevlieghere | 2019-07-18 17:17:42 +0200 (Thu, 18 Jul 2019) | 19 lines

[CMake] Don't set Python_ADDITIONAL_VERSIONS

Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.

However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.

Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.

This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.

Differential revision: https://reviews.llvm.org/D64894
------------------------------------------------------------------------

llvm-svn: 369899

------------------------------------------------------------------------
r369364 | miyuki | 2019-08-20 12:19:55 +0200 (Tue, 20 Aug 2019) | 6 lines

[libcxx] Fix build breakage on mips

Fixes https://bugs.llvm.org/show_bug.cgi?id=43011 caused by
https://reviews.llvm.org/D63284.

Committing as obvious.
------------------------------------------------------------------------

llvm-svn: 369898

llvm-svn: 369897

By Amy Huang!

llvm-svn: 369896

By Aras Pranckevicius!

llvm-svn: 369895

------------------------------------------------------------------------
r369694 | akhuang | 2019-08-22 21:40:07 +0200 (Thu, 22 Aug 2019) | 1 line

[COFF] Add libcall symbols to the link when LTO is being used
------------------------------------------------------------------------

llvm-svn: 369883

------------------------------------------------------------------------
r366836 | nico | 2019-07-23 21:00:01 +0200 (Tue, 23 Jul 2019) | 24 lines

ld.lld: Demangle symbols from archives in diagnostics

This ports r366573 from COFF to ELF.

There are now to toString(Archive::Symbol), one doing MSVC demangling
in COFF and one doing Itanium demangling in ELF, so rename these two
to toCOFFString() and to toELFString() to not get a duplicate symbol.

Nothing ever passes a raw Archive::Symbol to CHECK(), so these not
being part of the normal toString() machinery seems ok.

There are two code paths in the ELF linker that emits this type of
diagnostic:

1. The "normal" one in InputFiles.cpp. This is covered by the tweaked test.

2. An additional one that's only used for libcalls if there's at least
   one bitcode in the link, and if the libcall symbol is lazy, and
   lazily loaded from an archive (i.e. not from a lazy .o file).
   (This code path was added in r339301.) Since all libcall names so far
   are C symbols and never mangled, the change there is not observable
   and hence not covered by tests.

Differential Revision: https://reviews.llvm.org/D65095
------------------------------------------------------------------------

llvm-svn: 369882

------------------------------------------------------------------------
r366573 | nico | 2019-07-19 15:29:10 +0200 (Fri, 19 Jul 2019) | 6 lines

lld-link: Demangle symbols from archives in diagnostics

Also add test coverage for thin archives (which are the only way I could
come up with to test at least some of the diagnostic changes).

Differential Revision: https://reviews.llvm.org/D64927
------------------------------------------------------------------------

llvm-svn: 369881

------------------------------------------------------------------------
r369349 | ibiryukov | 2019-08-20 10:54:30 +0200 (Tue, 20 Aug 2019) | 36 lines

[clangd] Skip function bodies inside processed files while indexing

Summary:
This significantly improves performance of background indexing.

We do not collect references and declarations inside the processed
files, so this does not affect the final indexing results.

The idea is borrowed from libclang, which has a similar optimization in
its indexing functionality.

Measurements show a nice decrease in indexing time, up to ~40% for
building the whole index. These are not proper benchmarks, so one should
not rely on these results too much.

1. Rebuilding the whole index for LLVM:
  - Before. Total time: 14m58s.
    ./bin/clangd -pch-storage=memory < ./clangd.input  23917.67s user 515.86s system 2718% cpu 14:58.68 total
  - After. Total time: 8m41s.
    ./bin/clangd -pch-storage=memory < ./clangd.input  13627.29s user 288.10s system 2672% cpu 8:40.67 total

2. Rebuilding index after removing shards matching '*clangd*' (case-insensitively):
  - Before. Total time: 30s.
    ./bin/clangd -pch-storage=memory < ./clangd.input  130.94s user 6.82s system 452% cpu 30.423 total
  - After. Total time: 26s.
    ./bin/clangd -pch-storage=memory < ./clangd.input  80.51s user 5.40s system 333% cpu 25.777 total

Reviewers: kadircet, sammccall

Reviewed By: kadircet

Subscribers: MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66226
------------------------------------------------------------------------

llvm-svn: 369879

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

llvm-svn: 369758

llvm-svn: 369753