Summary:
This patch replaces incorrectt assert with a check. Previously it asserts that
if SCEV cannot prove `isKnownPredicate(A != B)`, then it should be able to prove
`isKnownPredicate(A == B)`.

Both these fact may be not provable. It is shown in the provided test:

Could not prove: `{-294,+,-2}<%bb1> !=  0`
Asserting: `{-294,+,-2}<%bb1> == 0`

Obviously, this SCEV is not equal to zero, but 0 is in its range so we cannot
also prove that it is not zero.

Instead of assert, we should be checking the required conditions explicitly.

Reviewers: lebedev.ri, fhahn, sanjoy, fedor.sergeev
Reviewed By: lebedev.ri
Subscribers: hiraditya, zzheng, javed.absar, llvm-commits

Tags: #llvm

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

Summary: Copy of https://reviews.llvm.org/D72072, submitting with ilya-biryukov's permission.

Reviewers: gribozavr2

Reviewed By: gribozavr2

Subscribers: cfe-commits

Tags: #clang

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

Summary: The return type modification has already been implemented in rL364840 and rL365290.

Reviewers: ldionne, mclow.lists, EricWF, #libc!

Reviewed By: ldionne

Subscribers: christof, dexonsmith, libcxx-commits

Tags: #libc

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

Summary: This patch adds the basic utilities to deal with dropable uses. dropable uses are uses that we rather drop than prevent transformations, for now they are limited to uses in llvm.assume.

Reviewers: jdoerfert, sstefan1

Reviewed By: jdoerfert

Subscribers: uenoku, lebedev.ri, mgorny, hiraditya, dexonsmith, llvm-commits

Tags: #llvm

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

Reviewers: lebedev.ri, jdoerfert

Reviewed By: jdoerfert

Subscribers: jdoerfert, dexonsmith, llvm-commits

Tags: #llvm

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

This patch adds basic strict-fp intrinsics support to PowerPC backend,
including basic arithmetic operations (add/sub/mul/div).

Reviewed By: steven.zhang, andrew.w.kaylor

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

Summary:
Cost modelling strikes again.
In PR44668 <https://bugs.llvm.org/show_bug.cgi?id=44668> patch series,
i've made the same mistake of always using generic `getOperationCost()`
that i missed in reviewing D73480/D74495 which was later fixed
in 62dd44d7.

We should be using more specific hooks instead - `getCastInstrCost()`,
`getArithmeticInstrCost()`, `getCmpSelInstrCost()`.

Evidently, this does not have an effect on the existing testcases,
with unchanged default cost budget. But if it *does* have an effect
on some target, we'll have to segregate tests that use this function
per-target, much like we already do with other TTI-aware transform tests.

There's also an issue that @samparker has brought up in post-commit-review:
>>! In D73501#1905171, @samparker wrote:
> Hi,
> Did you get performance numbers for these patches? We track the performance
> of our (Arm) open source DSP library and the cost model fixes were generally
> a notable improvement, so many thanks for that! But the final patch
> for rewriting exit values has generally been bad, especially considering
> the gains from the modelling improvements. I need to look into it further,
> but on my current test case I'm seeing +30% increase in stack accesses
> with a similar decrease in performance.
> I'm just wondering if you observed any negative effects yourself?

I don't know if this addresses that, or we need D66450 for that.

Reviewers: samparker, spatel, mkazantsev, reames, wmi

Reviewed By: reames

Subscribers: kristof.beyls, hiraditya, danielkiss, llvm-commits, samparker

Tags: #llvm

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

Summary: When narrowing a scalar G_EXTRACT where the destination lines up perfectly with a single result of the emitted G_UNMERGE_VALUES a COPY should be emitted instead of unconditionally trying to emit a G_MERGE_VALUES.

Reviewers: arsenm, dsanders

Reviewed By: arsenm

Subscribers: wdng, rovka, hiraditya, volkan, llvm-commits

Tags: #llvm

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

The note section type implies a specific format that this section does
not have thus tools like readelf fail here. Progbits has no format and
another pipeline compiler already sets the type to progbits.

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

Delete dead code from 8fffa404.

Summary:
Currently, a BoundaryAlign fragment may be inserted after the branch
that needs to be aligned to truncate the current fragment, this fragment is
unused at most of time. To avoid that, we can insert a new empty Data
fragment instead. Non-relaxable instruction is usually emitted into Data
fragment, so the inserted empty Data fragment will be reused at a high
possibility.

Reviewers: annita.zhang, reames, MaskRay, craig.topper, LuoYuanke, jyknight

Reviewed By: reames, LuoYuanke

Subscribers: llvm-commits, dexonsmith, hiraditya

Tags: #llvm

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

Add the workaround for the X86::MOV16ri when describing call site
parameters.

This reverts commit dfecec65.

Merging the change revealed that there is a failure on the memory
sanitizer bots.

    Command Output (stderr):
    --
    ==3569==WARNING: MemorySanitizer: use-of-uninitialized-value
        #0 0x1d71bff in
           llvm::AVRSubtarget::ParseSubtargetFeatures(llvm::StringRef,
    llvm::StringRef)
    /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/Target/AVR/AVRGenSubtargetInfo.inc:471:7
        #1 0x1d721f8 in initializeSubtargetDependencies
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRSubtarget.cpp:50:3
        #2 0x1d721f8 in llvm::AVRSubtarget::AVRSubtarget(llvm::Triple
           const&, std::__1::basic_string<char, std::__1::char_traits<char>,
    std::__1::allocator<char> > const&, std::__1::basic_string<char,
    std::__1::char_traits<char>, std::__1::allocator<char> > const&,
    llvm::AVRTargetMachine const&)
    /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRSubtarget.cpp:33:18
        #3 0x1d3077f in
           llvm::AVRTargetMachine::AVRTargetMachine(llvm::Target const&,
    llvm::Triple const&, llvm::StringRef, llvm::StringRef,
    llvm::TargetOptions const&, llvm::Optional<llvm::Reloc::Model>,
    llvm::Optional<llvm::CodeModel::Model>, llvm::CodeGenOpt::Level, bool)
    /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRTargetMachine.cpp:52:7
        #4 0x1d3169d in
           llvm::RegisterTargetMachine<llvm::AVRTargetMachine>::Allocator(llvm::Target
    const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef,
    llvm::TargetOptions const&, llvm::Optional<llvm::Reloc::Model>,
    llvm::Optional<llvm::CodeModel::Model>, llvm::CodeGenOpt::Level, bool)
    /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/TargetRegistry.h:1121:16
        #5 0x86662f in createTargetMachine
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/TargetRegistry.h:402:12
        #6 0x86662f in compileModule(char**, llvm::LLVMContext&)
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:473:52
        #7 0x861f42 in main
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:356:22
        #8 0x7f76f7b072e0 in __libc_start_main
           (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
        #9 0x7ebbc9 in _start
           (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/llc+0x7ebbc9)

    SUMMARY: MemorySanitizer: use-of-uninitialized-value
    /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/Target/AVR/AVRGenSubtargetInfo.inc:471:7
    in llvm::AVRSubtarget::ParseSubtargetFeatures(llvm::StringRef,
    llvm::StringRef)
    Exiting
    FileCheck error: '<stdin>' is empty.
    --

The patch wiill be re-committed once fixed.

Summary:
This patch makes the AVR backend an official target of LLVM, serving
as a request for comments for moving the AVR backend out of
experimental.

A future patch will move the LLVM AVR buildbot (llvm-avr-linux) from the
staging buildmaster to the production buildmaster, so error emails will
start to go out.

Summary of the backend
----------------------

  - 16-bit little endian
  - AsmParser based assembly parser
  - uses the MC library for generating AVR ELFs
  - most logic driven from standard TableGen-erated tables like other
    backends
  - passes all of the test suite under `check-all`, including generic
    CodeGen and DebugInfo tests
  - Used in two frontends
  - Limited, but functional support for DebugInfo and LLVM DWARF dumping
  - Binary compatible with AVR-GCC and avr-{libc,libgcc} for the most part
  - Cannot lower 32-bit shifts due to a bug, can lower shifts larger or
    smaller
  - Supports assembly/MC for all the entire AVR ISA, generally generates poorly
    optimized machine instructions, with most focus thus far on correctness

I've added reviewers and subscribers from previous patches where backends were made official,
and those who participated in the recent thread on llvm-dev, please add anybody I've missed.

The most recent discussion on this topic can be found in the llvm-dev thread [Moving the AVR backend out of experimental](https://lists.llvm.org/pipermail/llvm-dev/2020-February/139158.html)

Reviewers: chandlerc, lattner, rengolin, tstellar, arsenm, thakis, simoll, asb

Reviewed By: rengolin, thakis

Subscribers: CryZe, wdng, mgorny, aprantl, Jim, hans, aykevl, llvm-commits

Tags: #llvm

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

This patch is intend to implement the missing P8 MacroFusion for LLVM
according to Power8 User's Manual Section 10.1.12 Instruction Fusion

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

https://github.com/apple/swift/pull/30112/ makes the Swift standard
library for iOS build for arm64e. If you're building Swift against your
own LLVM, this in turn requires having the builtins built for arm64e,
otherwise you won't be able to use the builtins (which will in turn lead
to an undefined symbol for `__isOSVersionAtLeast`). Make the builtins
build for arm64e to fix this.

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

I accidentally commited this while cherry-picking commits out of my
reflog.

This reverts commit ae73ab64.

This is a reimplementation of the optimization removed in D75964. The actual spill/fill optimization is handled by D76013, this one just worries about reducing the stackmap section size itself by eliminating redundant entries. As noted in the comments, we could go a lot further here, but avoiding the degenerate invoke case as we did before is probably "enough" in practice.

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

Summary:
This patch adds a timeout of 500ms to death tests. As we add multithreaded code and locks, deadlocks become more likely so timeout will be useful.

Additionally:
 - Better error handling in `invokeSubprocess`
 - Makes `ProcessStatus`'s methods const

Reviewers: sivachandra, MaskRay, gchatelet, PaulkaToast

Reviewed By: sivachandra, PaulkaToast

Subscribers: tschuett, libc-commits

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

Saves ~400 includes of related headers:

$ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \
    | grep '^[-+] ' | sort | uniq -c | sort -nr
    468 -    llvm-project/clang/include/clang/Basic/TargetInfo.h
    468 -    llvm-project/clang/include/clang/Basic/TargetCXXABI.h
    368 -    llvm-project/llvm/include/llvm/Support/CodeGen.h
    368 -    llvm-project/clang/include/clang/Basic/XRayInstr.h
    368 -    llvm-project/clang/include/clang/Basic/CodeGenOptions.h
    368 -    llvm-project/clang/include/clang/Basic/CodeGenOptions.def
    367 -    llvm-project/llvm/include/llvm/ADT/FloatingPointMode.h
    367 -    llvm-project/clang/include/clang/Basic/DebugInfoOptions.h

Summary: This patch adds a temporary `__assert_fail` and `assert` definition to make it available to internal llvm libc code. `__assert_fail` writes to fd 2 directly instead of `stderr`, using SYS_write. I have not put it in its own linux directory because this is temporary and it should be using stdio's api in the future. It does not currently print out the line number (although we could do that by stringifying `__LINE__` if reviewers wish).

Reviewers: sivachandra, gchatelet, PaulkaToast

Reviewed By: sivachandra

Subscribers: mgorny, MaskRay, tschuett, libc-commits

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

Summary:
callbr's indirect branches aren't expected to be taken, so reduce their
probabilities to 0 while increasing the default destination to 1. This
allows some code improvements through block placement.

Reviewers: nickdesaulniers

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

MachO symbol linkage is described by the desc field of the nlist entry, not the
type field.

It is ok to add dependencies on symbols that are ready, they should just be
skipped.

This updates the DEBUG_TYPE string in llvm-jitlink-macho.cpp to reflect the
change made to llvm-jitlink.cpp in 66128c48.

Reviewers: LuoYuanke, craig.topper, RKSimon, pengfei

Reviewed By: craig.topper

Subscribers: cfe-commits, llvm-commits

Tags: #clang

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

Reviewers: LuoYuanke, craig.topper, RKSimon, pengfei

Reviewed By: craig.topper

Subscribers: cfe-commits, llvm-commits

Tags: #clang

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

In order for dsymutil to collect .apinotes files (which capture
attributes such as nullability, Swift import names, and availability),
I want to propose adding an apinotes: field to DIModule that gets
translated into a DW_AT_LLVM_apinotes (path) nested inside
DW_TAG_module. This will be primarily used by LLDB to indirectly
extract the Swift names of Clang declarations that were deserialized
from DWARF.

<rdar://problem/59514626>

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

MLIR does not have a Sphinx configuration, this is just leading to build
failures at the moment.
The website https://mlir.llvm.org/ is using the Hugo generator to
process the markdown files.

Reviewers: LuoYuanke, craig.topper, RKSimon, pengfei

Reviewed By: craig.topper

Subscribers: cfe-commits, llvm-commits

Tags: #clang

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

Summary: Created a docker container to provide transparency and easy changes to the llvm-libc buildbot intfra.

Reviewers: sivachandra

Reviewed By: sivachandra

Subscribers: MaskRay, tschuett, libc-commits

Tags: #libc-project

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

[mlir][NFC] Use fold expressions instead of variadic class templates for adding operations/etc. to dialects.

Summary: This is much simpler, and also greatly reduces the generated template recursion stack.

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