Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).

MFC r360702:

Merge commit 4ca2cad94 from llvm git (by Justin Hibbits):

[PowerPC] Add clang -msvr4-struct-return for 32-bit ELF

Summary:

Change the default ABI to be compatible with GCC. For 32-bit ELF
targets other than Linux, Clang now returns small structs in
registers r3/r4. This affects FreeBSD, NetBSD, OpenBSD. There is no
change for 32-bit Linux, where Clang continues to return all structs
in memory.

Add clang options -maix-struct-return (to return structs in memory)
and -msvr4-struct-return (to return structs in registers) to be
compatible with gcc. These options are only for PPC32; reject them on
PPC64 and other targets. The options are like -fpcc-struct-return and
-freg-struct-return for X86_32, and use similar code.

To actually return a struct in registers, coerce it to an integer of
the same size. LLVM may optimize the code to remove unnecessary
accesses to memory, and will return i32 in r3 or i64 in r3:r4.

Fixes PR#40736

Patch by George Koehler!

Reviewed By: jhibbits, nemanjai
Differential Revision: https://reviews.llvm.org/D73290

Requested by: jhibbits

MFC r361410:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.1-rc1-0-gf79cd71e145 (aka 10.0.1 rc1).

MFC r362235 (by kp):

llvm: Default to -mno-relax on RISC-V

Compiling on a RISC-V system fails with 'relocation R_RISCV_ALIGN
requires unimplemented linker relaxation; recompile with -mno-relax'.

Our default linker (ld.lld) doesn't support relaxation, so default to
no-relax so we don't generate object files the linker can't handle.

Reviewed by: mhorne
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D25210

MFC r362445:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-97-g6f71678ecd2 (not quite 10.0.1 rc2, as more fixes are
still pending).

MFC r362587 (by cem):

Add WITH_CLANG_FORMAT option

clang-format is enabled conditional on either WITH_CLANG_EXTRAS or
WITH_CLANG_FORMAT. Some sources in libclang are build conditional on
either rule, and obviously the clang-format binary itself depends on the
rule.

clang-format could still use a manual page.

Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D25427

MFC r362609:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-129-gd24d5c8e308. Getting closer to 10.0.1-rc2.

MFC r362679:

Regenerate ReStructuredText based manpages for llvm-project tools:

* bugpoint.1
* clang.1
* llc.1
* lldb.1
* lli.1
* llvm-ar.1
* llvm-as.1
* llvm-bcanalyzer.1
* llvm-cov.1
* llvm-diff.1
* llvm-dis.1
* llvm-dwarfdump.1
* llvm-extract.1
* llvm-link.1
* llvm-mca.1
* llvm-nm.1
* llvm-pdbutil.1
* llvm-profdata.1
* llvm-symbolizer.1
* llvm-tblgen.1
* opt.1

Add newly generated manpages for:

* llvm-addr2line.1 (this is an alias of llvm-symbolizer)
* llvm-cxxfilt.1
* llvm-objcopy.1
* llvm-ranlib.1 (this is an alias of llvm-ar)

Note that llvm-objdump.1 is an exception, as upstream has both a plain
.1 file, and a .rst variant. These will have to be reconciled upstream
first.

MFC r362680:

Follow-up to r362679, add more entries to OptionalObsoleteFiles.inc

MFC r362719:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.1-rc2-0-g77d76b71d7d.

Also add a few more llvm utilities under WITH_CLANG_EXTRAS:

* llvm-dwp, a utility for merging DWARF 5 Split DWARF .dwo files into
.dwp (DWARF package files)
* llvm-size, a size(1) replacement
* llvm-strings, a strings(1) replacement

MFC r362733:

Remove older llvm-ranlib.1 entry from ObsoleteFiles.inc, as it has
gotten its own manpage now, and should be no longer be removed by "make
delete-old".

MFC r362734:

Fix llvm-strings.1 not installing, this was a copy/paste error.

MFC r363401:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).

There were no changes since rc2, except in the upstream regression
tests, which we do not ship.

Relnotes: yes

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release), and a number of
follow-ups.

MFC r356479 (by bdragon):

[PowerPC] Fix libllvmminimal build when building from powerpc64 ELFv1.

When bootstrapping on powerpc64 ELFv1, it is necessary to use binutils
ld.bfd from ports for the bootstrap, as this is the only modern linker for
ELFv1 host tools.

As binutils ld.bfd is rather strict in its handling of undefined symbols,
it is necessary to pull in Support/Atomic.cpp to avoid an undefined symbol.

Reviewed by: dim, emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D23072

MFC r356930:

Add more Subversion mergeinfo bootstrap information, to hopefully
increase the probability of merging in vendor changes.

MFC r358408 (by brooks):

Merge commit 7214f7a79 from llvm git (by Sam Elliott):

[RISCV] Lower llvm.trap and llvm.debugtrap

Summary:
Until this commit, these have lowered to a call to abort().

`llvm.trap()` now lowers to `unimp`, which should trap on all systems.

`llvm.debugtrap()` now lowers to `ebreak`, which is exactly what this
instruction is for.

Reviewers: asb, luismarques

Reviewed By: asb

Tags: #llvm

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

This fixes miscompilation resulting in linking failures with
INVARIANTS disabled.

Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D23857

MFC r358851:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
10.0.0-rc3 c290cb61fdc.

Release notes for llvm, clang, lld and libc++ 10.0.0 will become
available here:

https://releases.llvm.org/10.0.0/docs/ReleaseNotes.html
https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html
https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html
https://releases.llvm.org/10.0.0/projects/libcxx/docs/ReleaseNotes.html

PR: 244251

MFC r358854:

Add one additional file to libllvmminimal, to help the ppc64 bootstrap.

Reported by: bdragon
PR: 244251

MFC r358857:

Move another file in libllvm from sources required for world, to sources
required for bootstrap, as the PowerPC builds need this.

Reported by: bdragon
PR: 244251

MFC r359082:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real
Soon Now.

PR: 244251

MFC r359084:

Merge commit 00925aadb from llvm git (by Fangrui Song):

[ELF][PPC32] Fix canonical PLTs when the order does not match the PLT order

Reviewed By: Bdragon28

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

This is needed to fix miscompiled canonical PLTs on ppc32/lld10.

Requested by: bdragon
Differential Revision: https://reviews.freebsd.org/D24109

MFC r359085:

Merge commit 315f8a55f from llvm git (by Fangrui Song):

[ELF][PPC32] Don't report "relocation refers to a discarded section"
for .got2

Similar to D63182 [ELF][PPC64] Don't report "relocation refers to a
discarded section" for .toc

Reviewed By: Bdragon28

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

This is needed to fix compile errors when building for ppc32/lld10.

Requested by: bdragon
Differential Revision: https://reviews.freebsd.org/D24110

MFC r359086:

Merge commit b8ebc11f0 from llvm git (by Sanjay Patel):

[EarlyCSE] avoid crashing when detecting min/max/abs patterns (PR41083)

As discussed in PR41083:
https://bugs.llvm.org/show_bug.cgi?id=41083
...we can assert/crash in EarlyCSE using the current hashing scheme
and instructions with flags.

ValueTracking's matchSelectPattern() may rely on overflow (nsw, etc)
or other flags when detecting patterns such as min/max/abs composed
of compare+select. But the value numbering / hashing mechanism used
by EarlyCSE intersects those flags to allow more CSE.

Several alternatives to solve this are discussed in the bug report.
This patch avoids the issue by doing simple matching of min/max/abs
patterns that never requires instruction flags. We give up some CSE
power because of that, but that is not expected to result in much
actual performance difference because InstCombine will canonicalize
these patterns when possible. It even has this comment for abs/nabs:

/// Canonicalize all these variants to 1 pattern.
/// This makes CSE more likely.

(And this patch adds PhaseOrdering tests to verify that the expected
transforms are still happening in the standard optimization
pipelines.

I left this code to use ValueTracking's "flavor" enum values, so we
don't have to change the callers' code. If we decide to go back to
using the ValueTracking call (by changing the hashing algorithm
instead), it should be obvious how to replace this chunk.

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

This fixes an assertion when building the math/gsl port on PowerPC64.

Requested by: pkubja

MFC r359087:

Merge commit 585a3cc31 from llvm git (by me):

Fix -Wdeprecated-copy-dtor and -Wdeprecated-dynamic-exception-spec
warnings.

Summary:
The former are like:

libcxx/include/typeinfo:322:11: warning: definition of implicit copy
constructor for 'bad_cast' is deprecated because it has a
user-declared destructor [-Wdeprecated-copy-dtor]
virtual ~bad_cast() _NOEXCEPT;
^
libcxx/include/typeinfo:344:11: note: in implicit copy constructor
for 'std::bad_cast' first required here
throw bad_cast();
^

Fix these by adding an explicitly defaulted copy constructor.

The latter are like:

libcxx/include/codecvt:105:37: warning: dynamic exception
specifications are deprecated [-Wdeprecated-dynamic-exception-spec]
virtual int do_encoding() const throw();
^~~~~~~

Fix these by using the _NOEXCEPT macro instead.

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

Reviewed By: EricWF, #libc

Subscribers: dexonsmith, libcxx-commits

Tags: #libc

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

This is because we use -Wsystem-headers during buildworld, and the two
warnings above are now triggered by default with clang 10, preventing
most C++ code from compiling without NO_WERROR.

Requested by: brooks
Differential Revision: https://reviews.freebsd.org/D24049

MFC r359333:

Merge commit f0990e104 from llvm git (by Justin Hibbits):

[PowerPC]: e500 target can't use lwsync, use msync instead

The e500 core has a silicon bug that triggers an illegal instruction
program trap on any sync other than msync. Other cores will typically
ignore illegal sync types, and the documentation even implies that
the 'illegal' bits are ignored.

Address this hardware deficiency by only using msync, like the PPC440.

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

Requested by: jhibbits

MFC r359334:

Merge commit 459e8e948 from llvm git (by Justin Hibbits):

[PowerPC]: Don't allow r0 as a target for LD_GOT_TPREL_L/32

Summary:
The linker is free to relax this (relocation R_PPC_GOT_TPREL16)
against R_PPC_TLS, if it sees fit (initial exec to local exec). If r0
is used, this can generate execution-invalid code (converts to 'addi
%rX, %r0, FOO, which translates in PPC-lingo to li %rX, FOO). Forbid
this instead.

This fixes static binaries using locales on FreeBSD/powerpc (tested
on FreeBSD/powerpcspe).

Reviewed By: nemanjai
Differential Revision: https://reviews.llvm.org/D76662

Requested by: jhibbits

MFC r359338:

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release).

PR: 244251

MFC r359506 (by emaste):

lldb: stop excluding bindings/ subdir

With liblua in the tree we should be able to enable lldb's lua
scripting. We'll need the files in bindings/, so start by allowing them
to come in with the next import.

Approved by: dim
Sponsored by: The FreeBSD Foundation

MFC r359578:

Merge once more from ^/vendor/llvm-project/release-10.x, to get the
lldb/bindings directory, which will be used to provide lua bindings for
lldb.

Requested by: emaste

MFC r359826:

Merge commit 30588a739 from llvm git (by Erich Keane):

Make target features check work with ctor and dtor-

The problem was reported in PR45468, applying target features to an
always_inline constructor/destructor runs afoul of GlobalDecl
construction assert when checking for target-feature compatibility.

The core problem is fixed by using the version of the check that
takes a FunctionDecl rather than the GlobalDecl. However, while
writing the test, I discovered that source locations weren't properly
set for this check on ctors/dtors. This patch also fixes constructors
and CALLED destructors.

Unfortunately, it doesn't seem too possible to get a meaningful
source location for a 'cleanup' destructor, so those are still
'frontend' level errors unfortunately. A fixme was added to the test
to cover that situation.

This should fix 'Assertion failed: (!isa<CXXConstructorDecl>(D) && "Use
other ctor with ctor decls!"), function Init, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/GlobalDecl.h, line
45' when compiling the security/botan2 port.

PR: 245550

MFC r359981:

Revert commit a9ad65a2b from llvm git (by Nemanja Ivanovic):

[PowerPC] Change default for unaligned FP access for older subtargets

This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40554

Some CPU's trap to the kernel on unaligned floating point access and
there are kernels that do not handle the interrupt. The program then
fails with a SIGBUS according to the PR. This just switches the
default for unaligned access to only allow it on recent server CPUs
that are known to allow this.

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

This upstream commit causes a compiler hang when building certain ports
(e.g. security/nss, multimedia/x264) for powerpc64. The hang has been
reported in https://bugs.llvm.org/show_bug.cgi?id=45186, but in the mean
time it is more convenient to revert the commit.

Requested by: jhibbits

MFC r359994:

Revert commit b6cf400aa fro llvm git (by Nemanja Ivanovic):

Fix bots after a9ad65a2b34f

In the last commit, I neglected to initialize the new subtarget
feature I added which caused failures on a few bots. This should fix
that.

This unbreaks the build after r359981, which reverted upstream commit
a9ad65a2b34f.

Reported by: jhibbits (and jenkins :)

MFC r360129:

Merge commit ce5173c0e from llvm git (by Reid Kleckner):

Use FinishThunk to finish musttail thunks

FinishThunk, and the invariant of setting and then unsetting
CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't
exist when I added this musttail codepath in ab2090d10765 (2014).
Recently in 28328c3771, I started using this codepath on non-Windows
platforms, and users reported problems during release testing
(PR44987).

The issue was already present for users of EH on i686-windows-msvc,
so I added a test for that case as well.

Reviewed By: hans

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

This should fix 'Assertion failed: (!empty() && "popping exception stack
when not empty"), function popTerminate, file
/usr/src/contrib/llvm-project/clang/lib/CodeGen/CGCleanup.h, line 583'
when building the net-p2p/libtorrent-rasterbar

PR: 244830
Reported by: jbeich, yuri

MFC r360134:

Merge commit 64b31d96d from llvm git (by Nemanja Ivanovic):

[PowerPC] Do not attempt to reuse load for 64-bit FP_TO_UINT without
FPCVT

We call the function that attempts to reuse the conversion without
checking whether the target matches the constraints that the callee
expects. This patch adds the check prior to the call.

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

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

This should fix 'Assertion failed: ((Op.getOpcode() == ISD::FP_TO_SINT
|| Subtarget.hasFPCVT()) && "i64 FP_TO_UINT is supported only with
FPCVT"), function LowerFP_TO_INTForReuse, file
/usr/src/contrib/llvm/lib/Target/PowerPC/PPCISelLowering.cpp, line 7276'
when building the devel/libslang2 port (and a few others) for PowerPC64.

Requested by: pkubaj

MFC r360350:

Tentatively apply https://reviews.llvm.org/D78877 (by Dave Green):

[ARM] Only produce qadd8b under hasV6Ops

When compiling for a arm5te cpu from clang, the +dsp attribute is
set. This meant we could try and generate qadd8 instructions where we
would end up having no pattern. I've changed the condition here to be
hasV6Ops && hasDSP, which is what other parts of ARMISelLowering seem
to use for similar instructions.

Fixed PR45677.

This fixes "fatal error: error in backend: Cannot select: t37: i32 =
ARMISD::QADD8b t43, t44" when compiling sys/dev/sound/pcm/feeder_mixer.c
for armv5. For some reason we do not encounter this on head, but this
error popped up while building universes for stable/12.

MFC r360697:

In r358396 I merged llvm upstream commit 2e24219d3, which fixed "error:
unsupported relocation on symbol" when assembling arm 'adr' pseudo
instructions. However, the upstream commit did not take big-endian arm
into account.

Applying the same changes to the big-endian handling is straightforward,
thanks to Andrew Turner and Peter Smith for the hint. This will also be
submitted upstream.

MFC r355940:

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp
9.0.0 final release r372316.

Release notes for llvm, clang, lld and libc++ 9.0.0 are available here:

https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html
https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html
https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html
https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html

PR: 240629
MFC after: 1 month

Pull in r360968 from upstream llvm trunk (by Philip Reames):

Clarify comments on helpers used by LFTR [NFC]

I'm slowly wrapping my head around this code, and am making comment
improvements where I can.

Pull in r360972 from upstream llvm trunk (by Philip Reames):

[LFTR] Factor out a helper function for readability purpose [NFC]

Pull in r360976 from upstream llvm trunk (by Philip Reames):

[IndVars] Don't reimplement Loop::isLoopInvariant [NFC]

Using dominance vs a set membership check is indistinguishable from a
compile time perspective, and the two queries return equivelent
results. Simplify code by using the existing function.

Pull in r360978 from upstream llvm trunk (by Philip Reames):

[LFTR] Strengthen assertions in genLoopLimit [NFCI]

Pull in r362292 from upstream llvm trunk (by Nikita Popov):

[IndVarSimplify] Fixup nowrap flags during LFTR (PR31181)

Fix for https://bugs.llvm.org/show_bug.cgi?id=31181 and partial fix
for LFTR poison handling issues in general.

When LFTR moves a condition from pre-inc to post-inc, it may now
depend on value that is poison due to nowrap flags. To avoid this, we
clear any nowrap flag that SCEV cannot prove for the post-inc addrec.

Additionally, LFTR may switch to a different IV that is dynamically
dead and as such may be arbitrarily poison. This patch will correct
nowrap flags in some but not all cases where this happens. This is
related to the adoption of IR nowrap flags for the pre-inc addrec.
(See some of the switch_to_different_iv tests, where flags are not
dropped or insufficiently dropped.)

Finally, there are likely similar issues with the handling of GEP
inbounds, but we don't have a test case for this yet.

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

Pull in r362971 from upstream llvm trunk (by Philip Reames):

Prepare for multi-exit LFTR [NFC]

This change does the plumbing to wire an ExitingBB parameter through
the LFTR implementation, and reorganizes the code to work in terms of
a set of individual loop exits. Most of it is fairly obvious, but
there's one key complexity which makes it worthy of consideration.
The actual multi-exit LFTR patch is in D62625 for context.

Specifically, it turns out the existing code uses the backedge taken
count from before a IV is widened. Oddly, we can end up with a
different (more expensive, but semantically equivelent) BE count for
the loop when requerying after widening. For the nestedIV example
from elim-extend, we end up with the following BE counts:
BEFORE: (-2 + (-1 * %innercount) + %limit)
AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>)

This is the only test in tree which seems sensitive to this
difference. The actual result of using the wider BETC on this example
is that we actually produce slightly better code. :)

In review, we decided to accept that test change. This patch is
structured to preserve the old behavior, but a separate change will
immediate follow with the behavior change. (I wanted it separate for
problem attribution purposes.)

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

Pull in r362975 from upstream llvm trunk (by Philip Reames):

[LFTR] Use recomputed BE count

This was discussed as part of D62880. The basic thought is that
computing BE taken count after widening should produce (on average)
an equally good backedge taken count as the one before widening.
Since there's only one test in the suite which is impacted by this
change, and it's essentially equivelent codegen, that seems to be a
reasonable assertion. This change was separated from r362971 so that
if this turns out to be problematic, the triggering piece is obvious
and easily revertable.

For the nestedIV example from elim-extend.ll, we end up with the
following BE counts:
BEFORE: (-2 + (-1 * %innercount) + %limit)
AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>)

Note that before is an i32 type, and the after is an i64. Truncating
the i64 produces the i32.

Pull in r362980 from upstream llvm trunk (by Philip Reames):

Factor out a helper function for readability and reuse in a future
patch [NFC]

Pull in r363613 from upstream llvm trunk (by Philip Reames):

Fix a bug w/inbounds invalidation in LFTR (recommit)

Recommit r363289 with a bug fix for crash identified in pr42279.
Issue was that a loop exit test does not have to be an icmp, leading
to a null dereference crash when new logic was exercised for that
case. Test case previously committed in r363601.

Original commit comment follows:

This contains fixes for two cases where we might invalidate inbounds
and leave it stale in the IR (a miscompile). Case 1 is when switching
to an IV with no dynamically live uses, and case 2 is when doing
pre-to-post conversion on the same pointer type IV.

The basic scheme used is to prove that using the given IV (pre or
post increment forms) would have to already trigger UB on the path to
the test we're modifying. As such, our potential UB triggering use
does not change the semantics of the original program.

As was pointed out in the review thread by Nikita, this is defending
against a separate issue from the hasConcreteDef case. This is about
poison, that's about undef. Unfortunately, the two are different, see
Nikita's comment for a fuller explanation, he explains it well.

(Note: I'm going to address Nikita's last style comment in a separate
commit just to minimize chance of subtle bugs being introduced due to
typos.)

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

Pull in r363875 from upstream llvm trunk (by Philip Reames):

[LFTR] Rename variable to minimize confusion [NFC]

(Recommit of r363293 which was reverted when a dependent patch was.)

As pointed out by Nikita in D62625, BackedgeTakenCount is generally
used to refer to the backedge taken count of the loop. A conditional
backedge taken count - one which only applies if a particular exit is
taken - is called a ExitCount in SCEV code, so be consistent here.

Pull in r363877 from upstream llvm trunk (by Philip Reames):

[LFTR] Stylistic cleanup as suggested in last review comment of
D62939 [NFC]

(Resumbit of r363292 which was reverted along w/an earlier patch)

Pull in r364346 from upstream llvm trunk (by Philip Reames):

[LFTR] Adjust debug output to include extensions (if any)

Pull in r364693 from upstream llvm trunk (by Philip Reames):

[IndVars] Remove a bit of manual constant folding [NFC]

SCEV is more than capable of folding (add x, trunc(0)) to x.

Pull in r364709 from upstream llvm trunk (by Nikita Popov):

[LFTR] Fix post-inc pointer IV with truncated exit count (PR41998)

Fixes https://bugs.llvm.org/show_bug.cgi?id=41998. Usually when we
have a truncated exit count we'll truncate the IV when comparing
against the limit, in which case exit count overflow in post-inc form
doesn't matter. However, for pointer IVs we don't do that, so we have
to be careful about incrementing the IV in the wide type.

I'm fixing this by removing the IVCount variable (which was ExitCount
or ExitCount+1) and replacing it with a UsePostInc flag, and then
moving the actual limit adjustment to the individual cases (which
are: pointer IV where we add to the wide type, integer IV where we
add to the narrow type, and constant integer IV where we add to the
wide type).

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

Together, these should fix a hang when building the textproc/htmldoc
port, due to an incorrect loop optimization.

PR: 237515
MFC after: 1 week

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The
release will follow very soon, but no more functional changes are
expected.

Release notes for llvm, clang and lld 8.0.0 will soon be available here:
<https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html>
<https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html>
<https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html>

PR: 236062
Relnotes: yes
MFC after: 1 month

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The
release will follow very soon, but no more functional changes are
expected.

Release notes for llvm, clang and lld 7.0.0 are available here:
<http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html>
<http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html>

PR: 230240, 230355
Relnotes: yes
MFC after: 2 months

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 (branches/release_60 r321788). Upstream has branched for the
6.0.0 release, which should be in about 6 weeks. Please report bugs and
regressions, so we can get them into the release.

Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.

MFC after: 3 months

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
5.0.0 (trunk r308421). Upstream has branched for the 5.0.0 release,
which should be in about a month. Please report bugs and regressions,
so we can get them into the release.

Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.

MFC after: 2 months

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
4.0.0 (branches/release_40 296509). The release will follow soon.

Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.

Also note that as of 4.0.0, lld should be able to link the base system
on amd64 and aarch64. See the WITH_LLD_IS_LLD setting in src.conf(5).
Though please be aware that this is work in progress.

Release notes for llvm, clang and lld will be available here:
<http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html>
<http://releases.llvm.org/4.0.0/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/4.0.0/tools/lld/docs/ReleaseNotes.html>

Thanks to Ed Maste, Jan Beich, Antoine Brodin and Eric Fiselier for
their help.

Relnotes: yes
Exp-run: antoine
PR: 215969, 216008
MFC after: 1 month

Pull in r278160 from upstream llvm trunk (by Wei Mi):

Recommit "Use ValueOffsetPair to enhance value reuse during SCEV
expansion".

The fix for PR28705 will be committed consecutively.

In D12090, the ExprValueMap was added to reuse existing value during
SCEV expansion. However, const folding and sext/zext distribution can
make the reuse still difficult.

A simplified case is: suppose we know S1 expands to V1 in
ExprValueMap, and
S1 = S2 + C_a
S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to
expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is
helpful when S2 is a complex SCEV expr and S2 has no entry in
ExprValueMap, which is usually caused by the fact that S3 is
generated from S1 after const folding.

In order to do that, we represent ExprValueMap as a mapping from SCEV
to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a}
into the ExprValueMap when we create SCEV for V1. When S3 is
expanded, it will first expand S2 to V1 - C_a because of S2->{V1,
C_a} in the map, then expand S3 to V1 - C_a + C_b.

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

Pull in r278161 from upstream llvm trunk (by Wei Mi):

Fix the runtime error caused by "Use ValueOffsetPair to enhance value
reuse during SCEV expansion".

The patch is to fix the bug in PR28705. It was caused by setting
wrong return value for SCEVExpander::findExistingExpansion. The
return values of findExistingExpansion have different meanings when
the function is used in different ways so it is easy to make mistake.
The fix creates two new interfaces to replace
SCEVExpander::findExistingExpansion, and specifies where each
interface is expected to be used.

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

Pull in r281439 from upstream llvm trunk (by Wei Mi):

Create a getelementptr instead of sub expr for ValueOffsetPair if the
value is a pointer.

This patch is to fix PR30213. When expanding an expr based on
ValueOffsetPair, if the value is of pointer type, we can only create
a getelementptr instead of sub expr.

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

This should fix assertion failures when building OpenCV >= 3.1, and also
allow building lang/spidermonkey24 without any further assertions.

PR: 215649
MFC after: 1 week

Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0
release, and add lld 3.9.0. Also completely revamp the build system for
clang, llvm, lldb and their related tools.

Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.

Release notes for llvm, clang and lld are available here:
<http://llvm.org/releases/3.9.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.9.0/tools/clang/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.9.0/tools/lld/docs/ReleaseNotes.html>

Thanks to Ed Maste, Bryan Drewery, Andrew Turner, Antoine Brodin and Jan
Beich for their help.

Relnotes: yes
MFC after: 1 month

Upgrade our copies of clang, llvm, lldb and compiler-rt to 3.8.0
release.

Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.

Release notes for llvm and clang will soon be available here:
<http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.8.0/tools/clang/docs/ReleaseNotes.html>

Thanks to Ed Maste, Roman Divacky, Davide Italiano and Antoine Brodin
for their help.

Relnotes: yes

Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.7.0
release.

Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.

Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html>

Thanks to Ed Maste, Andrew Turner and Antoine Brodin for their help.

Exp-run: antoine
Relnotes: yes

Upgrade our copy of clang, llvm and lldb to 3.6.0 release.

Please note that from 3.5.0 onwards, clang/llvm/lldb require C++11
support to build; see UPDATING for more information.

Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.6.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.6.0/tools/clang/docs/ReleaseNotes.html>

Thanks to Ed Maste for the lldb part of this upgrade.

Exp-run: antoine

Upgrade our copy of clang and llvm to 3.5.1 release. This is a bugfix
only release, no new features have been added.

Please note that this version requires C++11 support to build; see
UPDATING for more information.

Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.5.1/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.5.1/tools/clang/docs/ReleaseNotes.html>

MFC after: 1 month
X-MFC-With: 276479

Upgrade our copy of clang, llvm and lldb to 3.5.0 release.

Please note that this version now requires C++11 support to build; see
UPDATING for more information.

Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.5.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.5.0/tools/clang/docs/ReleaseNotes.html>

Thanks to Ed Maste, Roman Divacky, Andrew Turner, Justin Hibbits and
Antoine Brodin for their invaluable help with this import.

Approved by: portmgr (antoine)
MFC after: 1 month

Upgrade our copy of llvm/clang to 3.4 release. This version supports
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.

The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.

Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>

MFC after: 1 month

Upgrade our copy of llvm/clang to trunk r178860, in preparation of the
upcoming 3.3 release (branching and freezing expected in a few weeks).

Preliminary release notes can be found at the usual location:
<http://llvm.org/docs/ReleaseNotes.html>

An MFC is planned once the actual 3.3 release is finished.

Upgrade our copy of llvm/clang to r168974, from upstream's release_32
branch. This is effectively llvm/clang 3.2 RC2; the 3.2 release is
coming soon.

Upgrade our copy of llvm/clang to trunk r162107. With thanks to
Benjamin Kramer and Joerg Sonnenberger for their input and fixes.

Upgrade our copy of llvm/clang to trunk r154661, in preparation of the
upcoming 3.1 release (expected in a few weeks). Preliminary release
notes can be found at: <http://llvm.org/docs/ReleaseNotes.html>

MFC after: 2 weeks

Upgrade our copy of llvm/clang to r142614, from upstream's release_30
branch. This brings us very close to the 3.0 release, which is expected
in a week or two.

MFC after: 1 week

Upgrade our copy of llvm/clang to r135360, from upstream's trunk.

Upgrade our copy of llvm/clang to r132879, from upstream's trunk.

Upgrade our copy of llvm/clang to r130700, from upstream's trunk.

Upgrade our copy of llvm/clang to r126079, from upstream's trunk.

This contains many improvements, primarily better C++ support, an
integrated assembler for x86 and support for -pg.

Upgrade our Clang in base to r114020, from upstream's release_28 branch.

Approved-by: rpaulo (mentor)

Upgrade our Clang in base to r108428.

This commit merges the latest LLVM sources from the vendor space. It
also updates the build glue to match the new sources. Clang's version
number is changed to match LLVM's, which means /usr/include/clang/2.0
has been renamed to /usr/include/clang/2.8.

Obtained from: projects/clangbsd

Import LLVM/clang from vendor stripped of docs/ test/ website/ www/ examples/
in llvm/ and/or llvm/contrib/clang/ respectively.

Approved by: ed (mentor)
Approved by: core

Update LLVM to r103004.

Update LLVM to r100285.

Update LLVM to r100181.

Update LLVM to r99115.

Update LLVM to r98631.

Update LLVM to 97654.

Update LLVM to r96341.

Update LLVM to r94309.

Update LLVM to 93512.

Update LLVM to 92395.

Update LLVM to r89205.

Update LLVM to r86025.

Update llvm to r84119.

Import LLVM 74788.

Import LLVM r74383.

Import LLVM r73954.

Update LLVM sources to r73879.

Import LLVM r73340.

Import LLVM, at r72995.

We should now have support for #pragma weak.

Import LLVM, at r72805, which fixes PR4315 and PR4316.

Normally I'm not updating sources this often, but I want to get rid of
this breakage, because right now I can't offer a proper source snapshot
yet.

Import LLVM, at r72732.