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

(NOTE: This does not yet consolidate all the llvm project sources under
contrib/llvm-project (e.g., MFC r355940), due to Subversion limitations.
It will be done in a follow-up MFC.)

MFC r348610 (by emaste):

build llvm-ar and llvm-nm with Clang (promote out of CLANG_EXTRAS)

To facilitate experimentation with LTO we require an ar that supports
LLVM IR, and to a lesser degree also an nm. As a first step always
install llvm-ar and llvm-nm.

Sponsored by: The FreeBSD Foundation

MFC r350453 (by asomers):

Add a CXXWARNFLAGS variable

Some warning flags are valid for C++ but not C. GCC 8 complains if you pass
such flags when building a C file. Using a separate variable for these
flags allows building both C and C++ files in the same directory (such as
the fusefs tests) under GCC.

Reviewed by: cem, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21116

MFC r350467 (by luporl):

[PPC64] Backport fix for missing IRELATIVE relocations

This is a backport of LLVM commit 8331f61a51a7a0a1efbf5ed398e181593023d151,
llvm-svn: 353981:

ELF: Allow GOT relocs pointing to non-preemptable ifunc to resolve to an
IRELATIVE where possible.

This is needed in order to make ifuncs work correctly on PPC64.

It fixes an issue with lld, in which it would skip emitting necessary IRELATIVE
relocations. Without this change, indirect calls to ifuncs would result in a
segmentation fault, in static binaries or when defined in the main binary
(outside shared libraries).

This change also reverts the local
"Preserve relocations against ifuncs when -zifunc-noplt" commit and
replaces it by its upstream version, as part of the merge.

Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D21102

MFC r351662 (by emaste):

lldb: shorten thread names to make logs easier to follow

lldb prepends the thread name to log entries, and the existing thread
name for the FreeBSD ProcessMonitor thread was longer than the kernel's
supported thread name length, and so was truncated. This made logs hard
to read, as the truncated thread name ran into the log message. Shorten
"lldb.process.freebsd.operation" to just "freebsd.op" so that logs are
more readable.

(Upstreaming to lldb still to be done).

MFC r352095 (by emaste):

compiler-rt: use more __sanitizer_time_t on FreeBSD

A few structs were using long for time_t members.

Obtained from: LLVM r370755

MFC r352096 (by emaste):

compiler-rt: use 64-bit time_t for all FreeBSD archs except i386

Obtained from: LLVM r370756

MFC r352167 (by imp):

Remove dir empty since r276851

MFC r352168 (by imp):

Remove dirs empty since r280031

MFC r352169 (by imp):

Remove dir empty since r314564

MFC r352170 (by imp):

Remove dir empty since r327952

MFC r352171 (by imp):

Remove dirs (and their now-empty parents) empty since r344779

MFC r352792 (by emaste):

compiler-rt: correct RISC-V struct_kernel_stat64_sz

The value of struct_kernel_stat64_sz introduced by review D5021 for
RISC-V was incorrect.

Also add a __riscv_xlen == 64 conditional as the 32-bit ABI is not yet
finalized.

Submitted by: Luís Marques
Differential Revision: https://reviews.freebsd.org/D21684

MFC r353018 (by kevans):

clang: use -mxgot for 32-bit mips

Various bits in usr.bin/clang/* will fail to compile without -mxgot due to
truncated relocations. -mxgot entails a speed penalty, but I suspect we
don't care as much about compiler performance in 32-bit mips land.

Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D21698

MFC r353358:

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 r353363:

Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be
checked before access or destruction" when launching executables, while
we sort this out with upstream.

Reported by: jbeich
PR: 241137

MFC r353415:

Revert r353363 in preparation for applying upstream fix:

Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be
checked before access or destruction" when launching executables, while
we sort this out with upstream.

PR: 241137

MFC r353416:

Pull in r374444 from upstream lldb trunk (by me):

Fix process launch failure on FreeBSD after r365761

Summary:
After rLLDB365761, and with `LLVM_ENABLE_ABI_BREAKING_CHECKS`
enabled, launching any process on FreeBSD crashes lldb with:

```
Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in
success mode must still be checked prior to being destroyed).
```

This is because `m_operation_thread` and `m_monitor_thread` were
wrapped in `llvm::Expected<>`, but this requires the objects to be
correctly initialized before accessing them.

To fix the crashes, use `llvm::Optional<>` for the members (as
indicated by labath), and use local variables to store the return
values of `LaunchThread` and `StartMonitoringChildProcess`. Then,
only assign to the member variables after checking if the return
values indicated success.

Reviewers: devnexen, emaste, MaskRay, mgorny

Reviewed By: devnexen

Subscribers: jfb, labath, krytarowski, lldb-commits

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

PR: 241137

MFC r353579 (by jhb):

Use __FreeBSD_version to determine if gets() has been removed.

GCC compilers set __FreeBSD__ statically to a build-time determined
targeted version (which in ports always matches the build host's
version). This means that when building any version (12 or 13, etc.)
of riscv or some other architecture via GCC on a 12.x host,
__FreeBSD__ will always be set to 12. As a result, __FreeBSD__ cannot
be used to reliably detect the target FreeBSD version being built.
Instead, __FreeBSD_version from either <sys/param.h> (in the kernel)
or <osreldate.h> (in userland) should be used.

This changes the gets() test in libc++ to use __FreeBSD_version from
<osreldate.h>.

Reported by: jenkins (riscv64 and amd64-gcc)
Reviewed by: dim, imp
Differential Revision: https://reviews.freebsd.org/D22034

MFC r353711 (by mhorne):

Fix build of LLVM RISC-V backend

Reviewed by: dim
MFC with: r353358
Differential Revision: https://reviews.freebsd.org/D21963

MFC r353738:

Pull in r372651 from upstream lld trunk (by Simon Atanasyan):

[mips] Support elf32btsmipn32_fbsd / elf32ltsmipn32_fbsd emulations

Patch by Kyle Evans.

Requested by: kevans

MFC r353739:

Pull in r374154 from upstream clang trunk (by Simon Atanasyan):

[mips] Set default float ABI to "soft" on FreeBSD

Initial patch by Kyle Evans.

Fix PR43596

Requested by: kevans

MFC r353936:

Bump clang's default target CPU for the i386 architecture (aka "x86") to
i686, as per the discussion on the freebsd-arch mailing list. Earlier
in r352030, I had already bumped it to i586, to work around missing
atomic 64 bit functions for the i386 architecture.

Relnotes: yes

MFC r354097:

Pull in r372186 from upstream llvm trunk (by Eli Friedman):

[ARM] VFPv2 only supports 16 D registers.

r361845 changed the way we handle "D16" vs. "D32" targets; there used
to be a negative "d16" which removed instructions from the
instruction set, and now there's a "d32" feature which adds
instructions to the instruction set. This is good, but there was an
oversight in the implementation: the behavior of VFPv2 was changed.
In particular, the "vfp2" feature was changed to imply "d32". This is
wrong: VFPv2 only supports 16 D registers.

In practice, this means if you specify -mfpu=vfpv2, the compiler will
generate illegal instructions.

This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2"
and "vfp2sp" so they don't imply "d32".

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

Pull in r372187 from upstream clang trunk (by Eli Friedman):

[ARM] Update clang for removal of vfp2d16 and vfp2d16sp

Matching fix for https://reviews.llvm.org/D67375 (r372186).

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

This should fix clang generating invalid opcodes for floating point
operations on armv6.

Requested by: mmel

MFC r354146:

Pull in r373338 from upstream llvm trunk (by Simon Pilgrim):

Revert rL349624 : Let TableGen write output only if it changed,
instead of doing so in cmake, attempt 2

Differential Revision: https://reviews.llvm.org/D55842
-----------------
As discussed on PR43385 this is causing Visual Studio msbuilds to
perpetually rebuild all tablegen generated files

Pull in r373664 from upstream llvm trunk (by Nico Weber):

Reland r349624: Let TableGen write output only if it changed, instead
of doing so in cmake

Move the write-if-changed logic behind a flag and don't pass it with
the MSVC generator. msbuild doesn't have a restat optimization, so
not doing write-if-change there doesn't have a cost, and it should
fix whatever causes PR43385.

This should fix the scenario where an incremental build from before
r353358 (the clang 9.0.0 upgrade) to r353358 or later fails to update
the timestamp of the generated lib/clang/headers/arm_fp16.h header.

After such a build, installing world from read-only source and object
directories would attempt to generate the header again, leading to
"clang-tblgen: error opening arm_fp16.h.d:Read-only file system".

Reported by: avg, np
PR: 241402

MFC r354339:

Merge commit 97e362607 from llvm git (by Nemanja Ivanovic):

[PowerPC] Do not emit HW loop if the body contains calls to
lrint/lround

These two intrinsics are lowered to calls so should prevent the
formation of CTR loops. In a subsequent patch, we will handle all
currently known intrinsics and prevent the formation of HW loops if
any unknown intrinsics are encountered.

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

This should fix an "invalid CRT loop" assertion when building the
www/node port for powerpc64.

Requested by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br>

MFC r354347 (by cem):

Fix llvm-libunwind userspace build on ARM

GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or
EHABI or whatever it's called. Export the same ones from LLVM-libunwind's
libgcc_s, on ARM. As part of this, convert libgcc_s from a direct
Version.map to one constructed from component Symbol.map files. This allows
the ARM-specific Symbol.map to be included only on ARM.

Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match
non-ARM definitions and ARM-specific expectations in libcxxrt /
libcompiler_rt.

No functional change intended for non-ARM architectures.

This commit does not actually flip the switch for ARM defaults from libgcc
to llvm-libunwind, but makes it possible (to compile, anyway).

MFC r354418 (by cem):

clang: Enable unwind tables on !amd64

There doesn't seem to be much sense in defaulting "on" unwind tables on
amd64 and not on other arches. It causes surprising differences between
platforms, such as the PR below.

Prior to this change, FreeBSD inherited the default implementation of the
method from the Gnu.h Generic_Elf => Generic_GCC parent class, which
returned true only for amd64 targets. Override that and opt on always,
similar to, e.g., NetBSD.

PR: 241562
Reported by: lwhsu
Reviewed by: dim
Discussed with: emaste
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D22252

MFC r354429:

Merge commit 8e34dd941 from llvm git (by Sanjay Patel):

[x86] avoid crashing when splitting AVX stores with non-simple type
(PR43916)

The store splitting transform was assuming a simple type (MVT), but
that's not necessarily the case as shown in the test.

This should fix 'Assertion failed: (isSimple() && "Expected a
SimpleValueType!")' when building the security/openssl111 port targeting
a CPU that supports AVX, but not AVX2, such as sandybridge.

PR: 241747

MFC r354469:

Merge commit f596f4507 from llvm git (by Sam Elliott):

[RISCV] Add Custom Parser for Atomic Memory Operands

Summary:
GCC Accepts both (reg) and 0(reg) for atomic instruction memory
operands. These instructions do not allow for an offset in their
encoding, so in the latter case, the 0 is silently dropped.

Due to how we have structured the RISCVAsmParser, the easiest way to
add support for parsing this offset is to add a custom AsmOperand and
parser. This parser drops all the parens, and just keeps the
register.

This commit also adds a custom printer for these operands, which
matches the GCC canonical printer, printing both `(a0)` and `0(a0)`
as `(a0)`.

Reviewers: asb, lewis-revill

Reviewed By: asb

Subscribers: s.egerton, hiraditya, rbar, johnrusso, simoncook,
apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay,
zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o,
rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, llvm-commits

Tags: #llvm

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

llvm-svn: 367553

Merge commit f596f4507 from llvm git (by Sam Elliott):

[RISCV] Add FreeBSD targets

Reviewers: asb

Reviewed By: asb

Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne,
emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits

Tags: #clang

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

Patch by James Clarke (jrtc27)

llvm-svn: 367557

Merge commit f596f4507 from llvm git (by Hsiangkai Wang):

[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.

It is necessary to generate fixups in .debug_frame or .eh_frame as
relaxation is enabled due to the address delta may be changed after
relaxation.

There is an opcode with 6-bits data in debug frame encoding. So, we
also need 6-bits fixup types.

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

llvm-svn: 366524

Merge commit f596f4507 from llvm git (by Hsiangkai Wang):

[DebugInfo] Some fields do not need relocations even relax is enabled.

In debug frame information, some fields, e.g., Length in CIE/FDE and
Offset in FDE are attributes to describe the structure of CIE/FDE.
They are not related to the relaxed code. However, these attributes
are symbol differences. So, in current design, these attributes will
be filled as zero and LLVM generates relocations for them.

We only need to generate relocations for symbols in executable
sections. So, if the symbols are not located in executable sections,
we still evaluate their values under relaxation.

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

llvm-svn: 366531

Merge commit f596f4507 from llvm git (by Alex Bradbury):

[RISCV] Don't force absolute FK_Data_X fixups to relocs

The current behavior of shouldForceRelocation forces relocations for
the majority of fixups when relaxation is enabled. This makes sense
for fixups which incorporate symbols but is unnecessary for simple
data fixups where the fixup target is already resolved to an absolute
value.

Differential Revision: https://reviews.llvm.org/D63404
Patch by Edward Jones.

llvm-svn: 369257

Merge commit f596f4507 from llvm git (by Alex Bradbury):

[RISCV] Implement getExprForFDESymbol to ensure RISCV_32_PCREL is
used for the FDE location

Follow binutils in using RISCV_32_PCREL for the FDE initial location.
As explained in the relevant binutils commit
<https://github.com/riscv/riscv-binutils-gdb/commit/a6cbf936e3dce68114d28cdf60d510a3f78a6d40>,
the ADD/SUB pair of relocations is problematic in the presence of
linker relaxation.

This patch has the same end goal as D64715 but includes test changes
and avoids adding a new global VariantKind to MCExpr.h (preferring
RISCVMCExpr VKs like the rest of the RISC-V backend).

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

llvm-svn: 369375

This series of merges will permit riscv64 kernels and riscv64sf worlds
to build with clang instead of gcc (but still using the bfd linker).

Requested by: jhb
Obtained from: https://github.com/freebsd/freebsd/compare/master...bsdjhb:riscv_clang

MFC r354662 (by jhb):

Sync target triple generation with the version in Makefile.inc1.

Reviewed by: dim
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D22333

MFC r354692 (by emaste):

llvm: use AT_EXECPATH from ELF auxiliary vectors for getExecutablePath

/proc/curproc/file and the KERN_PROC_PATHNAME sysctl may not return the
desired path if there are multiple hardlinks to the file.

PR: 241932
Tested by: ler
Sponsored by: The FreeBSD Foundation

MFC r354707 (by emaste):

llvm: use elf_aux_info to get executable's path, if available

Obtained from: LLVM a0a38b81ea
MFC with: r354692
Sponsored by: The FreeBSD Foundation

MFC r354979:

Merge commit 7bed381ea from llvm git (by Simon Atanasyan):

[mips] Implement Octeon+ `saa` and `saad` instructions

`saa` and `saad` are 32-bit and 64-bit store atomic add instructions.

memory[base] = memory[base] + rt

These instructions are available for "Octeon+" CPU. The patch adds
support for both instructions to MIPS assembler and diassembler and
introduces new CPU type - "octeon+".

Next patches will implement `.set arch=octeon+` directive and
`AFL_EXT_OCTEONP` ISA extension flag support.

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

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354980:

Merge commit 3718102d4 from llvm git (by Simon Atanasyan):

[mips] Support `octeon+` CPU in the `.set arch=` directive

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

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354981:

Merge commit bf996f761 from llvm git (by Simon Atanasyan):

[mips] Write `AFL_EXT_OCTEONP` flag to the `.MIPS.abiflags` section

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

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354982:

Merge commit 3552d3e0f from llvm git (by Simon Atanasyan):

[mips] Add `octeon+` to the list of CPUs accepted by the driver

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354983:

Merge commit e578d0fd2 from llvm git (by Simon Atanasyan):

[mips] Fix `__mips_isa_rev` macros value for Octeon CPU

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354984:

Merge commit 0d14656b9 from llvm git (by Simon Atanasyan):

[mips] Set __OCTEON__ macros

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r354985:

Merge commit a751f557d from llvm git (by Simon Atanasyan):

[mips] Set macros for Octeon+ CPU

This is one of the upstream changes needed for adding support for the
OCTEON+ CPU type, so that we can test Clang builds using the most
commonly available FreeBSD/mips64 reference platform, the Edge Router
Lite.

Requested by: kevans

MFC r355397:

Merge commit 241cbf201 from llvm git (by Nemanja Ivanovic):

[PowerPC] Fix crash in peephole optimization

When converting reg+reg shifts to reg+imm rotates, we neglect to
consider the CodeGenOnly versions of the 32-bit shift mnemonics. This
means we produce a rotate with missing operands which causes a crash.

Committing this fix without review since it is non-controversial that
the list of mnemonics to consider should include the 64-bit aliases
for the exact mnemonics.

Fixes PR44183.

This should fix "Assertion failed: (idx < size()), function operator[],
file /usr/src/contrib/llvm/include/llvm/ADT/SmallVector.h, line 153"
when building the graphics/mesa-dri port for the PowerPC64 ELFv2 ABI.

Reported by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br>

MFC r355602:

Add a few missed source files to libllvm, for the MK_LLVM_TARGET_BPF=yes
case. Otherwise, linking of clang and other llvm based executables
would complain about missing symbols.

Reported by: rstone

MFC r355645 (by cem):

arm: libgcc_s: Fix ABI breakage introduced in r354347

Provide the symbol version for llvm-libunwind's _Unwind_Backtrace that libgcc
has historically provided on arm, in addition to the (default) standard version
used on all other arch.

Reported by: mmel

MFC r355803 (by mmel):

Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM.
In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version
for all architectures but ARM. For ARM should be publishes with GCC_4.3.0
version. This was originally omitted in r255095, fixed in r318024 and omitted
aging in LLVM libunwind implementation in r354347.

For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0
version , (because this is right original version) and again as
normal(not-default) with GCC_3.3 version (to maintain ABI compatibility
compiled/linked with wrong pre r318024 libgcc)

PR: 233664

Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release:

MFC r309142 (by emaste):

Add WITH_LLD_AS_LD build knob

If set it installs LLD as /usr/bin/ld. LLD (as of version 3.9) is not
capable of linking the world and kernel, but can self-host and link many
substantial applications. GNU ld continues to be used for the world and
kernel build, regardless of how this knob is set.

It is on by default for arm64, and off for all other CPU architectures.

Sponsored by: The FreeBSD Foundation

MFC r310840:

Reapply 310775, now it also builds correctly if lldb is disabled:

Move llvm-objdump from CLANG_EXTRAS to installed by default

We currently install three tools from binutils 2.17.50: as, ld, and
objdump. Work is underway to migrate to a permissively-licensed
tool-chain, with one goal being the retirement of binutils 2.17.50.

LLVM's llvm-objdump is intended to be compatible with GNU objdump
although it is currently missing some options and may have formatting
differences. Enable it by default for testing and further investigation.
It may later be changed to install as /usr/bin/objdump, it becomes a
fully viable replacement.

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

MFC r312855 (by emaste):

Rename LLD_AS_LD to LLD_IS_LD, for consistency with CLANG_IS_CC

Reported by: Dan McGregor <dan.mcgregor usask.ca>

MFC r313559 | glebius | 2017-02-10 18:34:48 +0100 (Fri, 10 Feb 2017) | 5 lines

Don't check struct rtentry on FreeBSD, it is an internal kernel structure.
On other systems it may be API structure for SIOCADDRT/SIOCDELRT.

Reviewed by: emaste, dim

MFC r314152 (by jkim):

Remove an assembler flag, which is redundant since r309124. The upstream
took care of it by introducing a macro NO_EXEC_STACK_DIRECTIVE.

http://llvm.org/viewvc/llvm-project?rev=273500&view=rev

Reviewed by: dim

MFC r314564:

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 r314708:

For now, revert r287232 from upstream llvm trunk (by Daniil Fukalov):

[SCEV] limit recursion depth of CompareSCEVComplexity

Summary:
CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled
loop) and runs almost infinite time.

Added cache of "equal" SCEV pairs to earlier cutoff of further
estimation. Recursion depth limit was also introduced as a parameter.

Reviewers: sanjoy

Subscribers: mzolotukhin, tstellarAMD, llvm-commits

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

This commit is the cause of excessive compile times on skein_block.c
(and possibly other files) during kernel builds on amd64.

We never saw the problematic behavior described in this upstream commit,
so for now it is better to revert it. An upstream bug has been filed
here: https://bugs.llvm.org/show_bug.cgi?id=32142

Reported by: mjg

MFC r314795:

Reapply r287232 from upstream llvm trunk (by Daniil Fukalov):

[SCEV] limit recursion depth of CompareSCEVComplexity

Summary:
CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled
loop) and runs almost infinite time.

Added cache of "equal" SCEV pairs to earlier cutoff of further
estimation. Recursion depth limit was also introduced as a parameter.

Reviewers: sanjoy

Subscribers: mzolotukhin, tstellarAMD, llvm-commits

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

Pull in r296992 from upstream llvm trunk (by Sanjoy Das):

[SCEV] Decrease the recursion threshold for CompareValueComplexity

Fixes PR32142.

r287232 accidentally increased the recursion threshold for
CompareValueComplexity from 2 to 32. This change reverses that
change by introducing a separate flag for CompareValueComplexity's
threshold.

The latter revision fixes the excessive compile times for skein_block.c.

MFC r314907 | mmel | 2017-03-08 12:40:27 +0100 (Wed, 08 Mar 2017) | 7 lines

Unbreak ARMv6 world.

The new compiler_rt library imported with clang 4.0.0 have several fatal
issues (non-functional __udivsi3 for example) with ARM specific instrict
functions. As temporary workaround, until upstream solve these problems,
disable all thumb[1][2] related feature.

MFC r315016:

Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release.
We were already very close to the last release candidate, so this is a
pretty minor update.

Relnotes: yes

MFC r316005:

Revert r314907, and pull in r298713 from upstream compiler-rt trunk (by
Weiming Zhao):

builtins: Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA.

Summary:
Value of __ARM_ARCH_ISA_THUMB isn't based on the actual compilation
mode (-mthumb, -marm), it reflect's capability of given CPU.

Due to this:
- use __tbumb__ and __thumb2__ insteand of __ARM_ARCH_ISA_THUMB
- use '.thumb' directive consistently in all affected files
- decorate all thumb functions using
DEFINE_COMPILERRT_THUMB_FUNCTION()

---------
Note: This patch doesn't fix broken Thumb1 variant of __udivsi3 !

Reviewers: weimingz, rengolin, compnerd

Subscribers: aemerson, dim

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

Discussed with: mmel

MFC r315689:

Gcc has incompatible internal declarations for __divtc3 and __multc3 as
defined in compiler-rt, but it has no option to silence its warning, so
make gcc warnings for libcompiler_rt non-fatal.

Noticed by: lwhsu

MFC r309124:

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 r309147:

Pull in r282174 from upstream llvm trunk (by Krzysztof Parzyszek):

[PPC] Set SP after loading data from stack frame, if no red zone is
present

Follow-up to r280705: Make sure that the SP is only restored after
all data is loaded from the stack frame, if there is no red zone.

This completes the fix for
https://llvm.org/bugs/show_bug.cgi?id=26519.

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

Reported by: Mark Millard
PR: 214433

MFC r309149:

Pull in r283060 from upstream llvm trunk (by Hal Finkel):

[PowerPC] Refactor soft-float support, and enable PPC64 soft float

This change enables soft-float for PowerPC64, and also makes
soft-float disable all vector instruction sets for both 32-bit and
64-bit modes. This latter part is necessary because the PPC backend
canonicalizes many Altivec vector types to floating-point types, and
so soft-float breaks scalarization support for many operations. Both
for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware
floating-point also disables vector instructions (embedded targets
without hardware floating point support are unlikely to have Altivec,
etc. and operating system kernels desiring not to use floating-point
registers to lower syscall cost are unlikely to want to use vector
registers either). If someone needs this to work, we'll need to
change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is
enabled, hardware floating-point support needs to be expressed as a
positive feature, like the others, and not a negative feature,
because target features cannot have dependencies on the disabling of
some other feature. So +soft-float has now become -hard-float.

Fixes PR26970.

Pull in r283061 from upstream clang trunk (by Hal Finkel):

[PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float

Enable soft-float support on PPC64, as the backend now supports it.
Also, the backend now uses -hard-float instead of +soft-float, so set
the target features accordingly.

Fixes PR26970.

Reported by: Mark Millard
PR: 214433

MFC r309212:

Add a few missed clang 3.9.0 files to OptionalObsoleteFiles.

MFC r309262:

Fix packaging for clang, lldb and lld 3.9.0

During the upgrade of clang/llvm etc to 3.9.0 in r309124, the PACKAGE
directive in the usr.bin/clang/*.mk files got dropped accidentally.

Restore it, with a few minor changes and additions:
* Correct license in clang.ucl to NCSA
* Add PACKAGE=clang for clang and most of the "ll" tools
* Put lldb in its own package
* Put lld in its own package

Reviewed by: gjb, jmallett
Differential Revision: https://reviews.freebsd.org/D8666

MFC r309656:

During the bootstrap phase, when building the minimal llvm library on
PowerPC, add lib/Support/Atomic.cpp. This is needed because upstream
llvm revision r271821 disabled the use of std::call_once, which causes
some fallback functions from Atomic.cpp to be used instead.

Reported by: Mark Millard
PR: 214902

MFC r309835:

Tentatively apply https://reviews.llvm.org/D18730 to work around gcc PR
70528 (bogus error: constructor required before non-static data member).
This should fix buildworld with the external gcc package.

Reported by: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/

MFC r310194:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
3.9.1 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, clang and lld will be available here:
<http://releases.llvm.org/3.9.1/docs/ReleaseNotes.html>
<http://releases.llvm.org/3.9.1/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/3.9.1/tools/lld/docs/ReleaseNotes.html>

Relnotes: yes

MFC r306266 (by emaste):

libcompiler_rt: use ${SRCTOP} for the top of the FreeBSD tree

MFC r306377 (by emaste):

libcompiler_rt: move file list to Makefile.inc for reuse elsewhere

Also switch to the style used in the clang390-import branch to reduce
future conflicts.

Reviewed by: dim
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8039

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Make armv6 hard float abi by default. Kill armv6hf.
Allow CPUTYPE=soft to build the current soft-float abi libraries.
Add UPDATING entry to announce this.

Approved by: re@ (gjb)

Merge the projects/release-pkg branch to head.

This allows packaging the base system with pkg(8), including
but not limited to providing the ability to provide upstream
binary update possibilities for non-tier-1 architectures.

This merge is a requirement of the 11.0-RELEASE, and as such,
thank you to everyone that has tested the project branch.

Documentation in build(7) etc. is still somewhat sparse, but
updates to those parts will follow.

Sponsored by: The FreeBSD Foundation

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

Annotate arm userspace assembler sources stating their tolerance to
the non-executable stack.

Reviewed by: andrew
Sponsored by: The FreeBSD Foundation

compiler_rt: add floatunsitf for arm64

It provides unsigned integer to quad-precision conversion.

Sponsored by: The FreeBSD Foundation

compiler-rt: include 128-bit quad precision fp support only on arm64

Other architectures do not use quad precision long double and don't need
these runtime support routines.

Differential Revision: https://reviews.freebsd.org/D2252
Reviewed by: dim
Sponsored by: The FreeBSD Foundation

compiler-rt: add floatditf and floatunditf

These are long integer (di_int/du_int) to quad precision floating point
conversions. They may be reworked based on upstream discussion. These
versions are here to support arm64 world builds.

Reviewed by: ed
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2174

compiler-rt: Implement multc3 - quad-precision complex multiplication

This may be reworked based on upstream discussion. This version is here
to support arm64 world builds.

Reviewed by: ed
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2173

compiler-rt: Build additional quad precision floating point builtins

These are needed for arm64

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2160

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

Pull in r231965 from upstream compiler-rt trunk (by Jörg Sonnenberger):

Refactor float to integer conversion to share the same code.
80bit Intel/PPC long double is excluded due to lacking support
for the abstraction. Consistently provide saturation logic.
Extend to long double on 128bit IEEE extended platforms.

Initial patch with test cases from GuanHong Liu.
Reviewed by Steve Canon.

Differential Revision: http://reviews.llvm.org/D2804

Pull in r232107 from upstream compiler-rt trunk (by Ed Maste):

Use signed int implementation for __fixint

Requested by: emaste

With the update of compiler-rt we try to build a number of files that
don't build on some ARM platforms, provide symbols we already provide in
libc, or don't exist. Remove these from the build. Some of these may
return later on specific targets.

Differential Revision: https://reviews.freebsd.org/D1468
Reviewed by: dim, imp

Update compiler-rt to trunk r224034. This brings a number of new
builtins, and also the various sanitizers. Support for these will be
added in a later commit.

Clean up detection of hard-float ABIs. As with big-endian in r272368 we
can check against arm*hf*.

Remove MK_ARM_EABI, the armeb issues have been fixed. The code to support
the oabi is still in the tree, but it is expected this will be removed
as developers work on surrounding code.

With this commit the ARM EABI is the only supported supported ABI by
FreeBSD on ARMa 32-bit processors.

X-MFC after: never
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D876

Use src.opts.mk in preference to bsd.own.mk except where we need stuff
from the latter.

Add a new ARM TARGET_ARCH, armv6hf. This is considered experimental.

This targets the existing ARMv6 and ARMv7 SoCs that contain a VFP unit.
This is an optional coprocessors may not be present in all devices, however
it appears to be in all current SoCs we support.

armv6hf targets the VFP variant of the ARM EABI and our copy of gcc is too
old to support this. Because of this there are a number of WITH/WITHOUT
options that are unsupported and must be left as the default value. The
options and their required value are:
* WITH_ARM_EABI
* WITHOUT_GCC
* WITHOUT_GNUCXX

In addition, without an external toolchain, the following need to be left
as their default:
* WITH_CLANG
* WITH_CLANG_IS_CC

As there is a different method of passing float and double values to
functions the ABI is incompatible with existing armv6 binaries. To use
this a full rebuild of world is required. Because no floating point values
are passed into the kernel an armv6 kernel with VFP enabled will work with
an armv6hf userland and vice versa.

Unconditionally compile the __sync_* atomics support functions into compiler-rt
for ARM.
This is quite ugly, because it has to work around a clang bug that does not
allow built-in functions to be defined, even when they're ones that are
expected to be built as part of a library.

Reviewed by: ed

Build __clear_cache on ARM with clang now it supports it.

Let ARM use the custom tailored atomic intrinsics.

Use improved __sync_*() intrinsics for MIPS in userspace as well.

r251524 introduced custom tailored versions for MIPS of these functions
for kernel-space code. We can just reuse them in userspace as well.

Add __sync_synchronize().

This function can easily be implemented on top of the mb() macro
provided by <machine/atomic.h>.

Unbreak <stdatomic.h> on ARM + Clang.

Clang only supports atomic operations for ARMv6. For non-ARMv6, we still
need to emit these functions.

Clang's prototype for these functions slightly differs, as it is truly
based on GCC's documentation. It requires the use of signed types, but
also requires varargs. Still, we are not allowed to simply implement
this function directly. Cleverly work around this by implementing it
under a different name and using __strong_reference().

Enable libcompiler-rt on MIPS.

Originally we disabled libcompiler-rt on MIPS and SPARC64, because of an
issue where __clzdi2 and __ctzdi2 would cause endless recursion. This
bug has been fixed in r230021 already, but for some reason we only
switched to libcompiler-rt on SPARC64 -- not MIPS.

This means we can finally use <stdatomic.h> on all our architectures.

Add the __aeabi_mem* functions to compiler-rt as clang uses them.

Use the compiler-rt version __{u,}divsi3 and __{u,}modsi3 on ARM EABI

There should have been a tab after SRCS+=

Add the __aeabi_*divmod functions to the compiler-rt build

Get libcompiler-rt and libgcc building on ARM with clang.

* Don't provide clear_cache or the __sync_* functions on ARM with clang as
they are provided by clang as builtin functions.
* Tell clang it is aloud to compile some libgcc code using heinous GCC
extensions.

Switch sparc64 to using libcompiler_rt; since r230021 we have a workaround
in place allowing it to be used there and since r235388 (see also r235486)
we also have usable div/mod optimizations like libgcc has.

Upgrade libcompiler_rt to upstream revision 147390.

This version of libcompiler_rt adds support for __mulo[sdt]i4(), which
computes a multiply and its overflow flag. There are also a lot of
cleanup fixes to headers that don't really affect us.

Updating to this revision should make it a bit easier to contribute
changes back to the LLVM developers.

Add locally implemented atomic intrinsics to libcompiler_rt.

The built-in atomic operations are not implemented in our version of GCC
4.2 for the ARM and MIPS architectures. Instead of emitting locked
instructions, they generate calls to functions that can be implemented
in the C runtime.

Only implement the atomic operations that are used by <stdatomic.h> for
datatype sizes that are supported by atomic(9). This means that on these
architectures, we can only use atomic operations on 32-bits and 64-bits
variables, which is typically sufficient.

This makes <stdatomic.h> work on all architectures except MIPS, since
MIPS and SPARC64 still use libgcc. Converting these architectures to
libcompiler_rt is on my todo list.

Upgrade libcompiler_rt from revision 117047 to 132478.

It seems there have only been a small amount to the compiler-rt source
code in the mean time. I'd rather have the code in sync as much as
possible by the time we release 9.0. Changes:

- The libcompiler_rt library is now dual licensed under both the
University of Illinois "BSD-Like" license and the MIT license.

- Our local modifications for using .hidden instead of .private_extern
have been upstreamed, meaning our changes to lib/assembly.h can now be
reverted.

- A possible endless recursion in __modsi3() has been fixed.

- Support for ARM EABI has been added, but it has no effect on FreeBSD
(yet).

- The functions __udivmodsi4 and __divmodsi4 have been added.

Requested by: many, including bf@ and Pedro Giffuni

Mark libcompiler_rt as not needed executable stack on powerpc.

Reviewed and tested by: nwhitehorn

Fix braino in r217101. -Wa is used to supply assembler flag to cc driver.

Noted by: Anonymous <swell.k gmail com>

On amd64 and i386, force assembler to mark objects compiled from the
assembler source for libcompiler_rt as not needed executable stack. This
is done with a hammer instead of properly marking each assembly file
with section .note.GNU-stack to avoid modifying contributed source.

Discussed with: ed

Switch mips architectures back to libgcc.

MIPS64 n64 binaries are broken with libcompiler_rt at this time.
Switch mips back to libgcc until the cause of breakage is analyzed
and fixed.

Revert to libgcc for sparc64.

I've had a report of a sparc64 system where cc1 generates illegal
instructions. We still have to diagnose this properly, but instead of
hosing all sparc64 boxes out there, fall back to libgcc to prevent more
damage.

Reported by: Florian Smeets

Set symbol visibility to hidden.

Not doing so may cause all sorts of random libraries to expose
libcompiler_rt's functions, which should of course not be done.

Discussed with: kan, kib

Import libcompiler_rt into HEAD and add Makefiles.

Obtained from: user/ed/compiler-rt