R_RISCV_{ADD,SET,SUB}* are used for local label computation.
Add a new RelExpr member R_RISCV_ADD to represent them.

R_RISCV_ADD is treated as a link-time constant because otherwise
R_RISCV_{ADD,SET,SUB}* are not allowed in -pie/-shared mode.
In glibc Scrt1.o, .rela.eh_frame contains such relocations.
Because .eh_frame is not writable, we get this error:

    ld.lld: error: can't create dynamic relocation R_RISCV_ADD32 against symbol: .L0 in readonly segment; recompil object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
    >>> defined in ..../riscv64-linux-gnu/lib/Scrt1.o

With D63076 and this patch, I can run -pie/-shared programs linked against glibc.

Note llvm-mc cannot currently produce R_RISCV_SET* so they are not tested.

Reviewed By: ruiu

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

llvm-svn: 363128

llvm-svn: 363127

Summary:
clang (as of 2019-06-12) / gcc (as of 8.2.1) PPC64 may emit a .rela.toc
which references an embedded switch table in a discarded .rodata/.text
section. The .toc and the .rela.toc are incorrectly not placed in the
comdat.

Technically a relocation from outside the group is not allowed by the ELF spec:

> A symbol table entry with STB_LOCAL binding that is defined relative
> to one of a group's sections, and that is contained in a symbol table
> section that is not part of the group, must be discarded if the group
> members are discarded. References to this symbol table entry from
> outside the group are not allowed.

Don't report errors to work around the bug.

This should fix the ppc64le-lld-multistage-test bot while linking llvm-tblgen:

    ld.lld: error: relocation refers to a discarded section: .rodata._ZNK4llvm3MVT13getSizeInBitsEv
    >>> defined in utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o
    >>> referenced by CodeGenRegisters.cpp
    >>> utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o:(.toc+0x0)

Some other PPC specific sections may have similar problems. We can blacklist more
section names when problems occur.

    // A simple program that reproduces the bug.
    // Note .rela.toc (outside the group) references a section symbol (STB_LOCAL) in a group.
    void puts(const char *);
    struct A {
      void foo(int a) {
        switch (a) {
        case 0: puts("0"); break;
        case 1: puts("1"); puts("1"); break;
        case 2: puts("2"); break;
        case 3: puts("3"); puts("4"); break;
        case 4: puts("4"); break;
        case 5: puts("5"); puts("5"); break;
        case 6: puts("6"); break;
        }
      }
      int a;
    };
    void foo(A x) { x.foo(x.a); }

Reviewers: ruiu, sfertile, espindola

Reviewed By: ruiu

Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 363126

The non-masked versions are already in there. I'm having some
trouble coming up with a way to test this right now. Most load
folding should happen during isel so I'm not sure how to get
peephole pass to do it.

llvm-svn: 363125

This reverts commit r363060 and restores r362867.

r362867 is innocent. The ppc64le-lld-multistage-test bot failure was due to a clang/gcc .toc bug:

    ld.lld: error: relocation refers to a discarded section: .rodata._ZNK4llvm3MVT13getSizeInBitsEv
    >>> defined in utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o
    >>> referenced by CodeGenRegisters.cpp
    >>>               utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o:(.toc+0x0)

It will be worked around by D63182.

llvm-svn: 363124

This test failed since CFI directive support was added in r361320.

llvm-svn: 363123

Port emmintrin.h which include Intel SSE2 intrinsics implementation to PowerPC platform (using Altivec).

The new headers containing those implemenations are located into a directory named ppc_wrappers
which has higher priority when the platform is PowerPC on Linux. They are mainly developed by Steven Munroe,
with contributions from Paul Clarke, Bill Schmidt, Jinsong Ji and Zixuan Wu.

It's a follow-up patch of D62121.

Patched by: Qiu Chaofan <qiucf@cn.ibm.com>

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

llvm-svn: 363122

Refactor Scop and ScopBuilder class:

1. Move hoistInvariantLoads function from Scop to ScopBuilder class.

2. Private functions (addInvariantLoads, getNonHoistableCtx) are moved
   to public section of Scop class. hoistInvariantLoads function
   references these functions. These functions will be moved to
   ScopBuilder as well in the next steps.

Patch by Dominik Adamski <adamski.dominik@gmail.com>

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

llvm-svn: 363121

In order to generate correct debug frame information, it needs to
generate CFI information in prologue and epilog.

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

llvm-svn: 363120

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

llvm-svn: 363119

llvm-svn: 363118

When applied to a typedef or alias template, the [[nodebug]] attribute
makes the typedef transparent to the debugger, so instead of seeing
`std::__function::__alloc_func<remove_reference<void(&)()>::type,
allocator<remove_reference<void(&)()>, void()>::_Target` you see
`void(&)()` as the type of the variable in your debugger.

Removing all this SFINAE noise from debug info has huge binary size
wins, in addition to improving the readability.

For now this change is on by default. Users can override it by
specifying -D_LIBCPP_NODEBUG_TYPE=

llvm-svn: 363117

According to System V i386 ABI: the  __m64 type paramater and return
value are passed by MMX registers. But current implementation treats
__m64 as i64 which results in parameter passing by stack and returning
by EDX and EAX.

This patch fixes the bug (https://bugs.llvm.org/show_bug.cgi?id=41029)
for Linux and NetBSD.

Patch by Wei Xiao (wxiao3)

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

llvm-svn: 363116

because it breaks the windows bot - asprintf() is not available.

llvm-svn: 363115

X86/avx512vl-intrinsics-fast-isel.ll is only partially complete.

llvm-svn: 363114

potentially-evaluated context.

This applies even if the use of the default argument is within an
unevaluated context.

llvm-svn: 363113

The issue is that if we have a loop with multiple predecessors outside the loop, the code was expecting to merge them and only return if equal, but instead returned the first one seen.

I have no idea if this actually tripped anywhere.  I noticed it by accident when reading the code and have no idea how to go about constructing a test case.

llvm-svn: 363112

llvm-svn: 363111

As we gear up to drop support for GCC in C++03, we should make clear
what our C++03 mode is, the C++11 extensions it provides,
and the C++11 extensions it depends on.

The section of this document discussing user-facing extensions has
been left blank while the community discusses new directions. For now
it's just a warning to users.

Additionally, the document contains examples of how these extensions
should be used and why. For example, using alias templates over class
templates.

llvm-svn: 363110

llvm-svn: 363109

We were only matching RHS being a loop invariant value, not the inverse. Since there's nothing which appears to canonicalize loop invariant values to RHS, this means we missed cases.

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

llvm-svn: 363108

Those fail on Green Dragon.

llvm-svn: 363107

We have the related getSplatValue() already in IR (see code just above the proposed addition).
But sometimes we only need to know that the value is a splat rather than capture the splatted
scalar value. Also, we have an isSplatValue() function already in SDAG.

Motivation - recent bugs that would potentially benefit from improved splat analysis in IR:
https://bugs.llvm.org/show_bug.cgi?id=37428
https://bugs.llvm.org/show_bug.cgi?id=42174

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

llvm-svn: 363106

Looks like a MachinePipeliner algorithm problem found by
sanitizer-x86_64-linux-fast.
I will backout this test first while investigating the problem to
unblock buildbot.

==49637==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x614000002e08 at pc 0x000004364350 bp 0x7ffe228a3bd0 sp 0x7ffe228a3bc8
READ of size 4 at 0x614000002e08 thread T0
    #0 0x436434f in
llvm::SwingSchedulerDAG::checkValidNodeOrder(llvm::SmallVector<llvm::NodeSet,
8u> const&) const
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:3736:11
    #1 0x4342cd0 in llvm::SwingSchedulerDAG::schedule()
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:486:3
    #2 0x434042d in
llvm::MachinePipeliner::swingModuloScheduler(llvm::MachineLoop&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:385:7
    #3 0x433eb90 in
llvm::MachinePipeliner::runOnMachineFunction(llvm::MachineFunction&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachinePipeliner.cpp:207:5
    #4 0x428b7ea in
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/CodeGen/MachineFunctionPass.cpp:73:13
    #5 0x4d1a913 in llvm::FPPassManager::runOnFunction(llvm::Function&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1648:27
    #6 0x4d1b192 in llvm::FPPassManager::runOnModule(llvm::Module&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1685:16
    #7 0x4d1c06d in runOnModule
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1752:27
    #8 0x4d1c06d in llvm::legacy::PassManagerImpl::run(llvm::Module&)
/b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/LegacyPassManager.cpp:1865
    #9 0xa48ca3 in compileModule(char**, llvm::LLVMContext&)
/b/sanitizer-x86_64-linux-fast/build/llvm/tools/llc/llc.cpp:611:8
    #10 0xa4270f in main
/b/sanitizer-x86_64-linux-fast/build/llvm/tools/llc/llc.cpp:365:22
    #11 0x7fec902572e0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
    #12 0x971b69 in _start
(/b/sanitizer-x86_64-linux-fast/build/llvm_build_asan/bin/llc+0x971b69)

llvm-svn: 363105

Reviewed By: delcypher

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

llvm-svn: 363104

In the latest OS betas, the objc runtime has a special interface
for the debugger, class_getNameRaw(), instead of the existing
class_getName(), which will return class names in their raw, unmangled
(in the case of swift) form.  When lldb can access the unmangled
names of classes, it won't need to fetch them out of the inferior
process after we run our "get the objc class table" expression.

If the new interface is absent (debugging a process on an older
target), lldb will fall back to class_getName and reading any class
names that it got back in demangled form, at a bit of a performance
cost on the first expression.

<rdar://problem/50688054> 

llvm-svn: 363103

llvm-svn: 363102

The call to getopt_long didn't handle the case where the *last* option
had an argument missing.

<rdar://problem/51231882>

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

llvm-svn: 363101

Summary:
This splits out a section in the command guide for llvm tools that can be used as replacements for GNU tools. For pages that didn't exist, I added stub pages that can be individually filled in by followup patches.

Tested by running `ninja docs-llvm-html` and inspecting locally.

Reviewers: jhenderson, MaskRay, grimar, alexshap

Reviewed By: jhenderson, MaskRay, grimar

Subscribers: smeenai, arphaman, llvm-commits

Tags: #llvm

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

llvm-svn: 363100

Mark CTAD fail tests for set/multiset as XFAIL for older compilers that give different error messages

llvm-svn: 363099

Summary:
This is the second patch to improve module loading in a series that started here (where I explain the motivation and solution): https://reviews.llvm.org/D62499

I need to read the aux vector to know where the r_debug map with the loaded libraries are.
The AuxVector class was made generic so it could be reused between the POSIX-DYLD plugin and NativeProcess*. The class itself ended up in the ProcessUtility plugin.

Reviewers: clayborg, xiaobai, labath, JDevlieghere

Reviewed By: clayborg, labath, JDevlieghere

Subscribers: emaste, JDevlieghere, mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 363098

llvm-svn: 363097

This opcode generates a pointer to the address of the jump table
specified by the source operand, which is a jump table index.

It will be used in conjunction with an upcoming G_BRJT opcode to support
jump table codegen with GlobalISel.

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

llvm-svn: 363096

Summary:
The more tests are added, the more we are limited by the size of the
address space on 32-bit. Implement `unmapTestOnly` all around (like it
is in sanitzer_common) to be able to free up some memory.
This is not intended to be a proper "destructor" for an allocator, but
allows us to not fail due to having no memory left.

Reviewers: morehouse, vitalybuka, eugenis, hctim

Reviewed By: morehouse

Subscribers: delcypher, jfb, #sanitizers, llvm-commits

Tags: #llvm, #sanitizers

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

llvm-svn: 363095

Summary: After applying a set of insert updates, there may be trivial Phis left over. Clean them up.

Reviewers: george.burgess.iv

Subscribers: jlebar, Prazek, llvm-commits

Tags: #llvm

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

llvm-svn: 363094

[NFC][CodeGen] Add unary FNeg tests to X86/combine-fcopysign.ll X86/dag-fmf-cse.ll X86/fast-isel-fneg.ll X86/fdiv.ll

llvm-svn: 363093

Our C++03 and C++11 implementations of function are not ABI
compatible. I've added a "test" that demonstrates this.

llvm-svn: 363092

Summary:
The method `getLoopPassPreservedAnalyses` should not mark MemorySSA as
preserved, because it's being called in a lot of passes that do not
preserve MemorySSA.
Instead, mark the MemorySSA analysis as preserved by each pass that does
preserve it.
These changes only affect the new pass mananger.

Reviewers: chandlerc

Subscribers: mehdi_amini, jlebar, Prazek, george.burgess.iv, llvm-commits

Tags: #llvm

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

llvm-svn: 363091

This is part of C++17's P0433.

Thanks to Arthur O'Dwyer for the patch.

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

llvm-svn: 363090

Summary: Deduplicate S_CONSTANTS when linking, if they have the same value.

Reviewers: rnk

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 363089