Fix https://bugs.llvm.org/show_bug.cgi?id=43830 while avoiding polluting the
global Python namespace.

This both reverts r357277 to rebundle a version of Python's readline module
based on libedit.

However, this patch also provides two improvements over the previous
implementation:

1. use PyMem_RawMalloc instead of PyMem_Malloc, as expected by PyOS_Readline
   (prevents to segfault upon exit of interactive session)
2. patch the readline module upon embedded interpreter loading, instead of
   patching it globally, which should prevent any side effect on other
   modules/packages
3. only activate the patched module if libedit is actually linked in lldb

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

(cherry picked from commit 9357b5d0)

------------------------------------------------------------------------
r370547 | wmi | 2019-08-30 16:01:22 -0700 (Fri, 30 Aug 2019) | 24 lines

[GVN] Verify value equality before doing phi translation for call instruction

This is an updated version of https://reviews.llvm.org/D66909 to fix PR42605.

Basically, current phi translatation translates an old value number to an new
value number for a call instruction based on the literal equality of call
expression, without verifying there is no clobber in between. This is incorrect.

To get a finegrain check, use MachineDependence analysis to do the job. However,
this is still not ideal. Although given a call instruction,
`MemoryDependenceResults::getCallDependencyFrom` returns identical call
instructions without clobber in between using MemDepResult with its DepType to
be `Def`. However, identical is too strict here and we want it to be relaxed a
little to consider phi-translation -- callee is the same, param operands can be
different. That means changing the semantic of `MemDepResult::Def` and I don't
know the potential impact.

So currently the patch is still conservative to only handle
MemDepResult::NonFuncLocal, which means the current call has no function local
clobber. If there is clobber, even if the clobber doesn't stand in between the
current call and the call with the new value, we won't do phi-translate.

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

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

------------------------------------------------------------------------
r373148 | aaronpuchert | 2019-09-28 06:28:50 -0700 (Sat, 28 Sep 2019) | 9 lines

Don't install example analyzer plugins

Summary: Fixes PR43430.

Reviewers: hintonda, NoQ, Szelethus, lebedev.ri

Reviewed By: lebedev.ri

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

Summary:
Rolls back the remaining bad optimizations introduced in
eb15d001. Some of them were already rolled back in e661f946 and
this finishes the job.

Fixes https://bugs.llvm.org/show_bug.cgi?id=44012.

Reviewers: dschuff, aheejin

Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

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

(cherry picked from commit 194d7ec0)

This makes it possible for this step to work during pull requests.

This prevents the tests from being run twice on pull requests
since pull requests first require creating a new branch (which was
also triggering CI runs).

------------------------------------------------------------------------
r367981 | maskray | 2019-08-05 23:25:32 -0700 (Mon, 05 Aug 2019) | 27 lines

[Driver] Prioritize SYSROOT/usr/include over RESOURCE_DIR/include on linux-musl

On a musl-based Linux distribution, stdalign.h stdarg.h stdbool.h stddef.h stdint.h stdnoreturn.h are expected to be provided by musl (/usr/include), instead of RESOURCE_DIR/include.
Reorder RESOURCE_DIR/include to fix the search order problem.
(Currently musl doesn't provide stdatomic.h. stdatomic.h is still found in RESOURCE_DIR/include.)

gcc on musl has a similar search order:

```
 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0
 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/x86_64-alpine-linux-musl
 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/backward
 /usr/local/include
 /usr/include/fortify
 /usr/include
 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/include
```

This is different from a glibc-based distribution where RESOURCE_DIR/include is placed before SYSROOT/usr/include.

According to the maintainer of musl:

> musl does not support use/mixing of compiler-provided std headers with its headers, and intentionally has no mechanism for communicating with such headers as to which types have already been defined or still need to be defined. If the current include order, with clang's headers before the libc ones, works in some situations, it's only by accident.

Reviewed by: phosek

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

Initial tests check for ABI changes and build/test llvm, clang, and lld.

Summary: This is a bug fix for further issues in PR43585.

Reviewers: rnk, RKSimon, craig.topper, andrew.w.kaylor

Subscribers: hiraditya, llvm-commits, annita.zhang

Tags: #llvm

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

(cherry picked from commit 8723b95c)

------------------------------------------------------------------------
r375403 | lenary | 2019-10-21 03:00:34 -0700 (Mon, 21 Oct 2019) | 30 lines

[MemCpyOpt] Fixing Incorrect Code Motion while Handling Aggregate Type Values

Summary:
When MemCpyOpt is handling aggregate type values, if an instruction (let's call it P) between the targeting load (L) and store (S) clobbers the source pointer of L, it will try to hoist S before P. This process will also hoist S's data dependency instructions.

However, the current implementation has a bug that if one of S's dependency instructions is //also// a user of P, MemCpyOpt will not prevent it from being hoisted above P and cause a use-before-define error. For example, in the newly added test file (i.e. `aggregate-type-crash.ll`), it will try to hoist both `store %my_struct %1, %my_struct* %3` and its dependent, `%3 = bitcast i8* %2 to %my_struct*`, above `%2 = call i8* @my_malloc(%my_struct* %0)`. Creating the following BB:
```
entry:
  %1 = bitcast i8* %4 to %my_struct*
  %2 = bitcast %my_struct* %1 to i8*
  %3 = bitcast %my_struct* %0 to i8*
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %2, i8* align 4 %3, i64 8, i1 false)
  %4 = call i8* @my_malloc(%my_struct* %0)
  ret void
```
Where there is a use-before-define error between `%1` and `%4`.

Update: The compiler for the Pony Programming Language [also encounter the same bug](https://github.com/ponylang/ponyc/issues/3140)

Patch by Min-Yih Hsu (myhsu)

Reviewers: eugenis, pcc, dblaikie, dneilson, t.p.northover, lattner

Reviewed By: eugenis

Subscribers: lenary, hiraditya, llvm-commits

Tags: #llvm

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

This change introduced a use of std::make_unique() which some compilers
reject in c++11 mode.

This still fixes PR43479, but does it in a way that does not change
the libLLVM-9.so ABI.

Summary:
Add instruction marker to MachineInstr ExtraInfo. This does almost the
same thing as Pre/PostInstrSymbols, except that it doesn't create a label until
printing instructions. This allows for labels to be put around instructions that
are deleted/duplicated somewhere.
Use this marker to track heap alloc site call instructions.

Reviewers: rnk

Subscribers: MatzeB, hiraditya, llvm-commits

Tags: #llvm

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

cherry picked from 74204304 with some
modifications.

This is a fix for PR43315. An assertion error is hit for this minimal example:

```
//clang -cc1 -triple x86_64-- -S tstVMStructRC-min.cpp
int (a b)();  // Assertion `Chunk.Kind == DeclaratorChunk::Function' failed.
```

This is because we do not cover the case in the FunctionTypeUnwrapper where it
receives a MacroQualifiedType. We have not run into this earlier because this
is a unique case where the __attribute__ contains both __cdecl__ and
__regparm__ (in that order), and we are compiling for x86_64. Changing the
architecture or the order of __cdecl__ and __regparm__ does not raise the
assertion.

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

(cherry picked from commit e278c138)

------------------------------------------------------------------------
r371733 | mgorny | 2019-09-12 06:06:12 -0700 (Thu, 12 Sep 2019) | 7 lines

[clang] [unittest] Import LLVMTestingSupport if necessary

Add LLVMTestingSupport directory from LLVM_MAIN_SRC_DIR when building
clang stand-alone and LLVMTestingSupport library is not present.  This
is needed to fix stand-alone builds without clang-tools-extra.

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

------------------------------------------------------------------------
r373397 | ctopper | 2019-10-01 14:55:55 -0700 (Tue, 01 Oct 2019) | 8 lines

[X86] convertToThreeAddress, make sure second operand of SUB32ri is really an immediate before calling getImm().

It might be a symbol instead. We can't fold those since we can't
negate them.

Similar for other SUB with immediates.

Fixes PR43529.
------------------------------------------------------------------------

------------------------------------------------------------------------
r373049 | hans | 2019-09-27 01:14:45 -0700 (Fri, 27 Sep 2019) | 4 lines

Fix the 'directory' field in DumpCompilationDatabase and add test

This broke in r371027 due to a missing negation
(llvm::sys::fs::current_path returns false on success).
------------------------------------------------------------------------

This reverts commit 3f594ed1.

This change has cause LLDB expression evaluation to fail on Arm Linux.

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

(cherry picked from commit a6c40f56)

------------------------------------------------------------------------
r372886 | spatel | 2019-09-25 08:08:33 -0700 (Wed, 25 Sep 2019) | 7 lines

[DAGCombiner] add one-use restriction to vector transform with cheap extract

We might be able to do better on the example in the test,
but in general, we should not scalarize a splatted vector
binop if there are other uses of the binop. Otherwise, we
can end up with code as we had - a scalar op that is
redundant with a vector op.
------------------------------------------------------------------------

------------------------------------------------------------------------
r372883 | spatel | 2019-09-25 07:57:45 -0700 (Wed, 25 Sep 2019) | 1 line

[x86] add test for multi-use scalarization of vector binop; NFC
------------------------------------------------------------------------

------------------------------------------------------------------------
r372675 | aemerson | 2019-09-23 17:09:23 -0700 (Mon, 23 Sep 2019) | 7 lines

[GlobalISel][IRTranslator] Fix switch table lowering to use signed LE not unsigned.

We were miscompiling switch value comparisons with the wrong signedness, which
shows up when we have things like switch case values with i1 types, which end up
being legalized incorrectly.

Fixes PR43383
------------------------------------------------------------------------

------------------------------------------------------------------------
r372038 | jcai19 | 2019-09-16 14:47:47 -0700 (Mon, 16 Sep 2019) | 15 lines

[compiler-rt][crt]  make test case nontrivial in check_cxx_section_exists

Summary:
.init_array gets optimized away when building with -O2 and as a result,
check_cxx_section_exists failed to pass -DCOMPILER_RT_HAS_INITFINI_ARRAY
when building crtbegin.o and crtend.o, which causes binaries linked with
them encounter segmentation fault. See https://crbug.com/855759 for
details. This change prevents .init_array section to be optimized away
even with -O2 or higher optimization level.

Subscribers: dberris, mgorny, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

------------------------------------------------------------------------
r374598 | atanasyan | 2019-10-11 14:51:33 -0700 (Fri, 11 Oct 2019) | 12 lines

[mips] Store 64-bit `li.d' operand as a single 8-byte value

Now assembler generates two consecutive `.4byte` directives to store
64-bit `li.d' operand. The first directive stores high 4-byte of the
value. The second directive stores low 4-byte of the value. But on
64-bit system we load this value at once and get wrong result if the
system is little-endian.

This patch fixes the bug. It stores the `li.d' operand as a single
8-byte value.

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

------------------------------------------------------------------------
r375077 | sbc | 2019-10-16 20:21:02 -0700 (Wed, 16 Oct 2019) | 10 lines

[lld][WebAssembly] Fix for weak references to data symbols in archives

Fix a bug where were not handling relocations against weakly undefined
data symbol.  Add a test for this case.  Also ensure that the weak
references to data symbols are not pulled in from archive files by
default (but are if `-u <name>` is added to the command line).

Fixes: PR43696

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

------------------------------------------------------------------------
r374544 | atanasyan | 2019-10-11 05:33:12 -0700 (Fri, 11 Oct 2019) | 12 lines

[mips] Fix loading "double" immediate into a GPR and FPR

If a "double" (64-bit) value has zero low 32-bits, it's possible to load
such value into a GP/FP registers as an instruction immediate. But now
assembler loads only high 32-bits of the value.

For example, if a target register is GPR the `li.d $4, 1.0` instruction
converts into the `lui $4, 16368` one. As a result, we get `0x3FF00000`
in the register. While a correct representation of the `1.0` value is
`0x3FF0000000000000`. The patch fixes that.

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

------------------------------------------------------------------------
r374548 | atanasyan | 2019-10-11 05:58:37 -0700 (Fri, 11 Oct 2019) | 1 line

[mips] Follow-up to r374544. Fix test case.
------------------------------------------------------------------------

------------------------------------------------------------------------
r374165 | atanasyan | 2019-10-09 06:12:27 -0700 (Wed, 09 Oct 2019) | 1 line

[mips] Rename local variable. NFC
------------------------------------------------------------------------

------------------------------------------------------------------------
r374164 | atanasyan | 2019-10-09 06:12:21 -0700 (Wed, 09 Oct 2019) | 8 lines

[mips] Split expandLoadImmReal into multiple methods. NFC

The `expandLoadImmReal` handles four different and almost non-overlapping
cases: loading a "single" float immediate into a GPR, loading a "single"
float immediate into a FPR, and the same couple for a "double" float
immediate.

It's better to move each `else if` branch into separate methods.
------------------------------------------------------------------------

This works around a bug in Debian's patchset for glibc. The bug is
described in detail in the upstream debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943798, but the short
version of it is that glibc on any Debian based distro don't load
libraries unless it has a .ARM.attribute section.

Reviewed by: jhenderson, rupprecht, MaskRay, jakehehrlich

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

Patch by Tobias Hieta.

(cherry picked from commit fb4a5501)

------------------------------------------------------------------------
r375265 | kerbowa | 2019-10-18 11:20:30 -0700 (Fri, 18 Oct 2019) | 13 lines

AMDGPU: Fix SMEM WAR hazard for gfx10 readlane

Summary: Hazard recognizer fails to see hazard with V_READLANE_B32_gfx10.

Reviewers: rampitec

Reviewed By: rampitec

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits

Tags: #llvm

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

------------------------------------------------------------------------
r368310 | sbc | 2019-08-08 09:58:36 -0700 (Thu, 08 Aug 2019) | 11 lines

[lld][WebAssembly] Add optional symbols after input file handling

This allows undefined references in input files be resolved by the
optional symbols.  Previously we were doing this before input file
reading which means it was working only for command line symbols
references (i.e. -u or --export).

Also use addOptionalDataSymbol for __dso_handle and make all optional
symbols hidden by default.

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

Summary:
This is an alternate approach to D63396

Currently funclets reuse the same stack slots that are used in the
parent function for saving callee-saved xmm registers. If the parent
function modifies a callee-saved xmm register before an excpetion is
thrown, the catch handler will overwrite the original saved value.

This patch allocates space in funclets stack for saving callee-saved xmm
registers and uses RSP instead RBP to access memory.

Signed-off-by: Pengfei Wang <pengfei.wang@intel.com>

Reviewers: rnk, RKSimon, craig.topper, annita.zhang, LuoYuanke, andrew.w.kaylor

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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



Signed-off-by: Pengfei Wang <pengfei.wang@intel.com>
llvm-svn: 370005
(cherry picked from commit 564fb58a)

Constexpr data member conversions work by starting with the class that
originally introduced the field, and converting from there to the type
that the user desires. Before this change, Clang was using the
inheritance model from the final destination class type instead of the
model from the class that originally introduced the field. To fix this,
find the relevant FieldDecl and take its parent class instead of using
the member pointer type the user provided.

Indirect field decls require some special handling to find the parent
class.

Fixes PR43803

(cherry picked from commit 07ee46d6)

Summary:
In the long run we should come up with another mechanism for marking
call instructions as heap allocation sites, and remove this workaround.
For now, we've had two bug reports about this, so let's apply this
workaround. SLH (the other client of instruction labels) probably has
the same bug, but the solution there is more likely to be to mark the
call instruction as not duplicatable, which doesn't work for debug info.

Reviewers: akhuang

Subscribers: aprantl, hiraditya, aganea, chandlerc, llvm-commits

Tags: #llvm

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

llvm-svn: 375137
(cherry picked from commit fc69ad09)

------------------------------------------------------------------------
r372188 | meinersbur | 2019-09-17 15:59:43 -0700 (Tue, 17 Sep 2019) | 13 lines

[CodeGen] Handle outlining of CopyStmts.

Since the removal of extensions nodes from schedule trees in r362257 it
is possible to emit parallel code for SCoPs containing
matrix-multiplications. However, the code looking for references used in
outlined statement was not prepared to handle CopyStmts introduced by
the matrix-matrix multiplication detection.

In this case, CopyStmts do not introduce references in addition to the
ones captured by MemoryAccesses, i.e. we change the assertion to accept
CopyStmts and add a regression test for this case.

This fixes llvm.org/PR43164
------------------------------------------------------------------------

llvm-svn: 374861

------------------------------------------------------------------------
r372020 | rnk | 2019-09-16 11:49:09 -0700 (Mon, 16 Sep 2019) | 30 lines

[PGO] Use linkonce_odr linkage for __profd_ variables in comdat groups

This fixes relocations against __profd_ symbols in discarded sections,
which is PR41380.

In general, instrumentation happens very early, and optimization and
inlining happens afterwards. The counters for a function are calculated
early, and after inlining, counters for an inlined function may be
widely referenced by other functions.

For C++ inline functions of all kinds (linkonce_odr &
available_externally mainly), instr profiling wants to deduplicate these
__profc_ and __profd_ globals. Otherwise the binary would be quite
large.

I made __profd_ and __profc_ comdat in r355044, but I chose to make
__profd_ internal. At the time, I was only dealing with coverage, and in
that case, none of the instrumentation needs to reference __profd_.
However, if you use PGO, then instrumentation passes add calls to
__llvm_profile_instrument_range which reference __profd_ globals. The
solution is to make these globals externally visible by using
linkonce_odr linkage for data as was done for counters.

This is safe because PGO adds a CFG hash to the names of the data and
counter globals, so if different TUs have different globals, they will
get different data and counter arrays.

Reviewers: xur, hans

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

------------------------------------------------------------------------
r372182 | rnk | 2019-09-17 14:10:49 -0700 (Tue, 17 Sep 2019) | 12 lines

[PGO] Don't use comdat groups for counters & data on COFF

For COFF, a comdat group is really a symbol marked
IMAGE_COMDAT_SELECT_ANY and zero or more other symbols marked
IMAGE_COMDAT_SELECT_ASSOCIATIVE. Typically the associative symbols in
the group are not external and are not referenced by other TUs, they are
things like debug info, C++ dynamic initializers, or other section
registration schemes. The Visual C++ linker reports a duplicate symbol
error for symbols marked IMAGE_COMDAT_SELECT_ASSOCIATIVE even if they
would be discarded after handling the leader symbol.

Fixes coverage-inline.cpp in check-profile after r372020.
------------------------------------------------------------------------

llvm-svn: 374858

------------------------------------------------------------------------
r372606 | spatel | 2019-09-23 06:30:23 -0700 (Mon, 23 Sep 2019) | 3 lines

[x86] fix assert with horizontal math + broadcast of vector (PR43402)

https://bugs.llvm.org/show_bug.cgi?id=43402
------------------------------------------------------------------------

llvm-svn: 374633

------------------------------------------------------------------------
r373275 | tstellar | 2019-09-30 16:42:17 -0700 (Mon, 30 Sep 2019) | 9 lines

Fix Driver/modules.cpp test to work when build directory name contains '.s'

Reviewers: dyung, rsmith, hansw

Subscribers: mati865, mgorny, cfe-commits

Tags: #clang

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

llvm-svn: 374605

Fixes PR43229.

Patch By:  Joseph Tremoulet

llvm-svn: 374511

Summary:
Patch for 9.0.1.

Simplified version of r372186/r372187: fix the meaning of the "vfpv2" and "vfpv2sp" features, but keep around the useless "vfp2d16" and "vfp2d16sp" features, to reduce the risk on the release branch.

Fixes https://bugs.llvm.org/show_bug.cgi?id=43365

Reviewers: t.p.northover, tstellar

Reviewed By: t.p.northover

Subscribers: kristof.beyls, hiraditya, kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 374433