update main to 15

Approved by: re (implicit)
Sponsored by: GoFundMe https://www.gofundme.com/f/gjbbsd
Sponsored by: PayPal https://paypal.me/gjbbsd

arm64 lib32: change clang to allow -m32 on arm64

The FreeBSD driver support for clang tested explicitly for 32-bit
Intel, MIPS, or PowerPC targets where /usr/lib32/libcrt1.o was
present to decide whether -m32 should use /usr/lib32. At jrtc27's
suggestion, simply test for a 32-bit platform rather than adding
arm to the list. Upstreamed as
https://github.com/llvm/llvm-project/commit/3450272fc281979388bb845a9fffb59b42cc2e7e
Bump the freebsd version to force a bootstrap build. This is one
step in adding support for -m32 on arm64.

Reviewed by: jrtc27, brooks, dim
Differential Revision: https://reviews.freebsd.org/D40943

Merge llvm-project release/16.x llvmorg-16.0.6-0-g7cbf1a259152

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.6-0-g7cbf1a259152 (aka 16.0.6 release).

PR: 271047
MFC after: 1 month

Merge llvm-project main llvmorg-16-init-18548-gb0daacf58f41

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16-init-18548-gb0daacf58f41.

PR: 271047
MFC after: 1 month

Merge llvm-project main llvmorg-15-init-15358-g53dc0f10787

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-15358-g53dc0f10787.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-10223-g401b76fdf2b3

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10223-g401b76fdf2b3.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.

PR: 258209
MFC after: 2 weeks

Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR: 255570
MFC after: 6 weeks

Bump CURRENT to 14.0

This one goes to 14.

Approved by: re (implicit)
Sponsored by: Rubicon Communications, LLC ("Netgate")

* Bump version numbers to 10.0.0
* Update UPDATING
* Update (Optional)ObsoleteFiles.inc
* Update VCS(Revision|Version) files
* Update generated config headers
* Update clang internal headers Makefile

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

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

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

PR: 240629
MFC after: 1 month

Prepare for merging back to head:
* Set tentative merge date
* Add UPDATING entry
* Bump __FreeBSD_version
* Bump FREEBSD_CC_VERSION
* Bump LLD_REVISION

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a
week or so.

MFC after: 2 weeks

Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch
r354130, resolve conflicts, and bump version numbers.

Update version numbers, and regenerate config headers for llvm, clang,
lld and lldb. Update ObsoleteFiles.inc and OptionalObsoleteFiles.inc.

Merge ^/head r339015 through r339669.

- Update head to 13.0-CURRENT.
- Bump MACHINE_TRIPLE, TARGET_TRIPLE, FBSD_MAJOR, FBSD_CC_VER,
FREEBSD_CC_VERSION, OS_VERSION.
- Update comment in UPDATING regarding debugging options.
- Remove debug.witness.trace=0 from installation media.
- Bump __FreeBSD_version.

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

clang: allow ifunc resolvers to accept arguments

Previously Clang required ifunc resolution functions to take no
arguments, presumably because GCC documented ifunc resolvers as taking
no arguments. However, GCC accepts resolvers accepting arguments, and
our rtld passes CPU ID information (cpuid, hwcap, etc.) to ifunc
resolvers. Just remove the check from the in-tree compiler for our in-
tree compiler; a different (per-OS) approach may be required upstream.

Reported by: mjg
Approved by: re (rgrimes)
MFC after: 1 week
Relnotes: Yes
Sponsored by: The FreeBSD Foundation

Merge llvm, clang, lld, lldb, compiler-rt and libc++ release_70 branch
r339355, resolve conflicts, and bump version numbers.

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.1 release (upstream r335540).

Relnotes: yes
MFC after: 2 weeks

Recommit r332501, with an additional upstream fix for "Cannot lower
EFLAGS copy that lives out of a basic block!" errors on i386.

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Pull in r330264 from upstream llvm trunk (by Chandler Carruth):

[x86] Fix PR37100 by teaching the EFLAGS copy lowering to rewrite
uses across basic blocks in the limited cases where it is very
straight forward to do so.

This will also be useful for other places where we do some limited
EFLAGS propagation across CFG edges and need to handle copy rewrites
afterward. I think this is rapidly approaching the maximum we can and
should be doing here. Everything else begins to require either heroic
analysis to prove how to do PHI insertion manually, or somehow
managing arbitrary PHI-ing of EFLAGS with general PHI insertion.
Neither of these seem at all promising so if those cases come up,
we'll almost certainly need to rewrite the parts of LLVM that produce
those patterns.

We do now require dominator trees in order to reliably diagnose
patterns that would require PHI nodes. This is a bit unfortunate but
it seems better than the completely mysterious crash we would get
otherwise.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Revert r332501 for now, as it can cause build failures on i386.
Reported upstream as <https://bugs.llvm.org/show_bug.cgi?id=37133>.

Reported by: emaste, ci.freebsd.org
PR: 225330

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 release (upstream r326565).

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

Relnotes: yes
MFC after: 3 months
X-MFC-With: r327952
PR: 224669

Bump clang's __FreeBSD_cc_version, to cope with r328816, which removed
-Wno-error=tautological-constant-compare again (this flag is now out of
-Wextra after upstream https://reviews.llvm.org/rL322901). Otherwise
the MK_SYSTEM_COMPILER logic will not build a cross-tools compiler.

Reported by: jpaetzel, tuexen, Stefan Hagen

Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko):

Allow usage of X86-prefixes as separate instrs.
Differential Revision: https://reviews.llvm.org/D42102

This should fix parse errors when x86 prefixes (such as 'lock' and
'rep') are followed by various non-mnemonic tokens, e.g. comments, .byte
directives and labels.

PR: 224669,225054

Bump FREEBSD_CC_VERSION.

Initial update of clang/llvm build glue, for building just a minimal
clang executable.

Bump FREEBSD_CC_VERSION to force bootstrap compiler build.

Merge ^/head r309170 through r309212.

Bump FREEBSD_CC_VERSION again for r309147 and 309149.

In preparation for merging back to head, bump __FreeBSD_version,
FREEBSD_CC_VERSION and set date in ObsoleteFiles.inc.

Pull in r265122 from upstream llvm trunk (by James Molloy):

Fix for pr24346: arm asm label calculation error in sub

Some ARM instructions encode 32-bit immediates as a 8-bit integer
(0-255) and a 4-bit rotation (0-30, even) in its least significant 12
bits. The original fixup, FK_Data_4, patches the instruction by the
value bit-to-bit, regardless of the encoding. For example, assuming
the label L1 and L2 are 0x0 and 0x104 respectively, the following
instruction:

add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260

would be assembled to the following, which adds 1 to r0, instead of
260:

e2800104 add r0, r0, #4, 2 ; equivalently 1

The new fixup kind fixup_arm_mod_imm takes care of the encoding:

e2800f41 add r0, r0, #260

Patch by Ting-Yuan Huang!

This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.

Requested by: jkim
MFC after: 3 days

Pull in r262772 from upstream clang trunk (by Simon Pilgrim):

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

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

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

This ensures clang does not emit AVX instructions for CPUTYPE=btver1.

Reported by: Michel Depeige <demik+freebsd@lostwave.net>
PR: 211864
MFC after: 3 days

Bump FREEBSD_CC_VERSION in lib/clang/freebsd_cc_version.h

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

For clang, move the definition of FREEBSD_CC_VERSION into its own header
file, lib/clang/freebsd_cc_version.h, instead of reusing Version.inc.
The header is only included from one .cpp file in the clang tree.

This minimizes the number of .cpp files that need to be rebuilt if the
version is bumped.

Discussed with: bdrewery

Merge llvm-project main llvmorg-15-init-15358-g53dc0f10787

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-15358-g53dc0f10787.

PR: 265425
MFC after: 2 weeks

Merge llvm-project main llvmorg-14-init-10223-g401b76fdf2b3

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10223-g401b76fdf2b3.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.

PR: 258209
MFC after: 2 weeks

Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR: 255570
MFC after: 6 weeks

Bump CURRENT to 14.0

This one goes to 14.

Approved by: re (implicit)
Sponsored by: Rubicon Communications, LLC ("Netgate")

* Bump version numbers to 10.0.0
* Update UPDATING
* Update (Optional)ObsoleteFiles.inc
* Update VCS(Revision|Version) files
* Update generated config headers
* Update clang internal headers Makefile

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

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

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

PR: 240629
MFC after: 1 month

Prepare for merging back to head:
* Set tentative merge date
* Add UPDATING entry
* Bump __FreeBSD_version
* Bump FREEBSD_CC_VERSION
* Bump LLD_REVISION

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a
week or so.

MFC after: 2 weeks

Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch
r354130, resolve conflicts, and bump version numbers.

Update version numbers, and regenerate config headers for llvm, clang,
lld and lldb. Update ObsoleteFiles.inc and OptionalObsoleteFiles.inc.

Merge ^/head r339015 through r339669.

- Update head to 13.0-CURRENT.
- Bump MACHINE_TRIPLE, TARGET_TRIPLE, FBSD_MAJOR, FBSD_CC_VER,
FREEBSD_CC_VERSION, OS_VERSION.
- Update comment in UPDATING regarding debugging options.
- Remove debug.witness.trace=0 from installation media.
- Bump __FreeBSD_version.

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

clang: allow ifunc resolvers to accept arguments

Previously Clang required ifunc resolution functions to take no
arguments, presumably because GCC documented ifunc resolvers as taking
no arguments. However, GCC accepts resolvers accepting arguments, and
our rtld passes CPU ID information (cpuid, hwcap, etc.) to ifunc
resolvers. Just remove the check from the in-tree compiler for our in-
tree compiler; a different (per-OS) approach may be required upstream.

Reported by: mjg
Approved by: re (rgrimes)
MFC after: 1 week
Relnotes: Yes
Sponsored by: The FreeBSD Foundation

Merge llvm, clang, lld, lldb, compiler-rt and libc++ release_70 branch
r339355, resolve conflicts, and bump version numbers.

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.1 release (upstream r335540).

Relnotes: yes
MFC after: 2 weeks

Recommit r332501, with an additional upstream fix for "Cannot lower
EFLAGS copy that lives out of a basic block!" errors on i386.

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Pull in r330264 from upstream llvm trunk (by Chandler Carruth):

[x86] Fix PR37100 by teaching the EFLAGS copy lowering to rewrite
uses across basic blocks in the limited cases where it is very
straight forward to do so.

This will also be useful for other places where we do some limited
EFLAGS propagation across CFG edges and need to handle copy rewrites
afterward. I think this is rapidly approaching the maximum we can and
should be doing here. Everything else begins to require either heroic
analysis to prove how to do PHI insertion manually, or somehow
managing arbitrary PHI-ing of EFLAGS with general PHI insertion.
Neither of these seem at all promising so if those cases come up,
we'll almost certainly need to rewrite the parts of LLVM that produce
those patterns.

We do now require dominator trees in order to reliably diagnose
patterns that would require PHI nodes. This is a bit unfortunate but
it seems better than the completely mysterious crash we would get
otherwise.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Revert r332501 for now, as it can cause build failures on i386.
Reported upstream as <https://bugs.llvm.org/show_bug.cgi?id=37133>.

Reported by: emaste, ci.freebsd.org
PR: 225330

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 release (upstream r326565).

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

Relnotes: yes
MFC after: 3 months
X-MFC-With: r327952
PR: 224669

Bump clang's __FreeBSD_cc_version, to cope with r328816, which removed
-Wno-error=tautological-constant-compare again (this flag is now out of
-Wextra after upstream https://reviews.llvm.org/rL322901). Otherwise
the MK_SYSTEM_COMPILER logic will not build a cross-tools compiler.

Reported by: jpaetzel, tuexen, Stefan Hagen

Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko):

Allow usage of X86-prefixes as separate instrs.
Differential Revision: https://reviews.llvm.org/D42102

This should fix parse errors when x86 prefixes (such as 'lock' and
'rep') are followed by various non-mnemonic tokens, e.g. comments, .byte
directives and labels.

PR: 224669,225054

Bump FREEBSD_CC_VERSION.

Initial update of clang/llvm build glue, for building just a minimal
clang executable.

Bump FREEBSD_CC_VERSION to force bootstrap compiler build.

Merge ^/head r309170 through r309212.

Bump FREEBSD_CC_VERSION again for r309147 and 309149.

In preparation for merging back to head, bump __FreeBSD_version,
FREEBSD_CC_VERSION and set date in ObsoleteFiles.inc.

Pull in r265122 from upstream llvm trunk (by James Molloy):

Fix for pr24346: arm asm label calculation error in sub

Some ARM instructions encode 32-bit immediates as a 8-bit integer
(0-255) and a 4-bit rotation (0-30, even) in its least significant 12
bits. The original fixup, FK_Data_4, patches the instruction by the
value bit-to-bit, regardless of the encoding. For example, assuming
the label L1 and L2 are 0x0 and 0x104 respectively, the following
instruction:

add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260

would be assembled to the following, which adds 1 to r0, instead of
260:

e2800104 add r0, r0, #4, 2 ; equivalently 1

The new fixup kind fixup_arm_mod_imm takes care of the encoding:

e2800f41 add r0, r0, #260

Patch by Ting-Yuan Huang!

This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.

Requested by: jkim
MFC after: 3 days

Pull in r262772 from upstream clang trunk (by Simon Pilgrim):

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

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

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

This ensures clang does not emit AVX instructions for CPUTYPE=btver1.

Reported by: Michel Depeige <demik+freebsd@lostwave.net>
PR: 211864
MFC after: 3 days

Bump FREEBSD_CC_VERSION in lib/clang/freebsd_cc_version.h

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

For clang, move the definition of FREEBSD_CC_VERSION into its own header
file, lib/clang/freebsd_cc_version.h, instead of reusing Version.inc.
The header is only included from one .cpp file in the clang tree.

This minimizes the number of .cpp files that need to be rebuilt if the
version is bumped.

Discussed with: bdrewery

Merge llvm-project main llvmorg-14-init-10223-g401b76fdf2b3

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10223-g401b76fdf2b3.

PR: 261742
MFC after: 2 weeks

Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.

PR: 258209
MFC after: 2 weeks

Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR: 255570
MFC after: 6 weeks

Bump CURRENT to 14.0

This one goes to 14.

Approved by: re (implicit)
Sponsored by: Rubicon Communications, LLC ("Netgate")

* Bump version numbers to 10.0.0
* Update UPDATING
* Update (Optional)ObsoleteFiles.inc
* Update VCS(Revision|Version) files
* Update generated config headers
* Update clang internal headers Makefile

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

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

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

PR: 240629
MFC after: 1 month

Prepare for merging back to head:
* Set tentative merge date
* Add UPDATING entry
* Bump __FreeBSD_version
* Bump FREEBSD_CC_VERSION
* Bump LLD_REVISION

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a
week or so.

MFC after: 2 weeks

Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch
r354130, resolve conflicts, and bump version numbers.

Update version numbers, and regenerate config headers for llvm, clang,
lld and lldb. Update ObsoleteFiles.inc and OptionalObsoleteFiles.inc.

Merge ^/head r339015 through r339669.

- Update head to 13.0-CURRENT.
- Bump MACHINE_TRIPLE, TARGET_TRIPLE, FBSD_MAJOR, FBSD_CC_VER,
FREEBSD_CC_VERSION, OS_VERSION.
- Update comment in UPDATING regarding debugging options.
- Remove debug.witness.trace=0 from installation media.
- Bump __FreeBSD_version.

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

clang: allow ifunc resolvers to accept arguments

Previously Clang required ifunc resolution functions to take no
arguments, presumably because GCC documented ifunc resolvers as taking
no arguments. However, GCC accepts resolvers accepting arguments, and
our rtld passes CPU ID information (cpuid, hwcap, etc.) to ifunc
resolvers. Just remove the check from the in-tree compiler for our in-
tree compiler; a different (per-OS) approach may be required upstream.

Reported by: mjg
Approved by: re (rgrimes)
MFC after: 1 week
Relnotes: Yes
Sponsored by: The FreeBSD Foundation

Merge llvm, clang, lld, lldb, compiler-rt and libc++ release_70 branch
r339355, resolve conflicts, and bump version numbers.

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.1 release (upstream r335540).

Relnotes: yes
MFC after: 2 weeks

Recommit r332501, with an additional upstream fix for "Cannot lower
EFLAGS copy that lives out of a basic block!" errors on i386.

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Pull in r330264 from upstream llvm trunk (by Chandler Carruth):

[x86] Fix PR37100 by teaching the EFLAGS copy lowering to rewrite
uses across basic blocks in the limited cases where it is very
straight forward to do so.

This will also be useful for other places where we do some limited
EFLAGS propagation across CFG edges and need to handle copy rewrites
afterward. I think this is rapidly approaching the maximum we can and
should be doing here. Everything else begins to require either heroic
analysis to prove how to do PHI insertion manually, or somehow
managing arbitrary PHI-ing of EFLAGS with general PHI insertion.
Neither of these seem at all promising so if those cases come up,
we'll almost certainly need to rewrite the parts of LLVM that produce
those patterns.

We do now require dominator trees in order to reliably diagnose
patterns that would require PHI nodes. This is a bit unfortunate but
it seems better than the completely mysterious crash we would get
otherwise.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Revert r332501 for now, as it can cause build failures on i386.
Reported upstream as <https://bugs.llvm.org/show_bug.cgi?id=37133>.

Reported by: emaste, ci.freebsd.org
PR: 225330

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 release (upstream r326565).

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

Relnotes: yes
MFC after: 3 months
X-MFC-With: r327952
PR: 224669

Bump clang's __FreeBSD_cc_version, to cope with r328816, which removed
-Wno-error=tautological-constant-compare again (this flag is now out of
-Wextra after upstream https://reviews.llvm.org/rL322901). Otherwise
the MK_SYSTEM_COMPILER logic will not build a cross-tools compiler.

Reported by: jpaetzel, tuexen, Stefan Hagen

Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko):

Allow usage of X86-prefixes as separate instrs.
Differential Revision: https://reviews.llvm.org/D42102

This should fix parse errors when x86 prefixes (such as 'lock' and
'rep') are followed by various non-mnemonic tokens, e.g. comments, .byte
directives and labels.

PR: 224669,225054

Bump FREEBSD_CC_VERSION.

Initial update of clang/llvm build glue, for building just a minimal
clang executable.

Bump FREEBSD_CC_VERSION to force bootstrap compiler build.

Merge ^/head r309170 through r309212.

Bump FREEBSD_CC_VERSION again for r309147 and 309149.

In preparation for merging back to head, bump __FreeBSD_version,
FREEBSD_CC_VERSION and set date in ObsoleteFiles.inc.

Pull in r265122 from upstream llvm trunk (by James Molloy):

Fix for pr24346: arm asm label calculation error in sub

Some ARM instructions encode 32-bit immediates as a 8-bit integer
(0-255) and a 4-bit rotation (0-30, even) in its least significant 12
bits. The original fixup, FK_Data_4, patches the instruction by the
value bit-to-bit, regardless of the encoding. For example, assuming
the label L1 and L2 are 0x0 and 0x104 respectively, the following
instruction:

add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260

would be assembled to the following, which adds 1 to r0, instead of
260:

e2800104 add r0, r0, #4, 2 ; equivalently 1

The new fixup kind fixup_arm_mod_imm takes care of the encoding:

e2800f41 add r0, r0, #260

Patch by Ting-Yuan Huang!

This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.

Requested by: jkim
MFC after: 3 days

Pull in r262772 from upstream clang trunk (by Simon Pilgrim):

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

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

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

This ensures clang does not emit AVX instructions for CPUTYPE=btver1.

Reported by: Michel Depeige <demik+freebsd@lostwave.net>
PR: 211864
MFC after: 3 days

Bump FREEBSD_CC_VERSION in lib/clang/freebsd_cc_version.h

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

For clang, move the definition of FREEBSD_CC_VERSION into its own header
file, lib/clang/freebsd_cc_version.h, instead of reusing Version.inc.
The header is only included from one .cpp file in the clang tree.

This minimizes the number of .cpp files that need to be rebuilt if the
version is bumped.

Discussed with: bdrewery

Merge llvm-project main llvmorg-13-init-16847-g88e66fa60ae5

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.

PR: 258209
MFC after: 2 weeks

Merge llvm-project main llvmorg-12-init-17869-g8e464dd76bef

This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.

PR: 255570
MFC after: 6 weeks

Bump CURRENT to 14.0

This one goes to 14.

Approved by: re (implicit)
Sponsored by: Rubicon Communications, LLC ("Netgate")

* Bump version numbers to 10.0.0
* Update UPDATING
* Update (Optional)ObsoleteFiles.inc
* Update VCS(Revision|Version) files
* Update generated config headers
* Update clang internal headers Makefile

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

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

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

PR: 240629
MFC after: 1 month

Prepare for merging back to head:
* Set tentative merge date
* Add UPDATING entry
* Bump __FreeBSD_version
* Bump FREEBSD_CC_VERSION
* Bump LLD_REVISION

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a
week or so.

MFC after: 2 weeks

Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch
r354130, resolve conflicts, and bump version numbers.

Update version numbers, and regenerate config headers for llvm, clang,
lld and lldb. Update ObsoleteFiles.inc and OptionalObsoleteFiles.inc.

Merge ^/head r339015 through r339669.

- Update head to 13.0-CURRENT.
- Bump MACHINE_TRIPLE, TARGET_TRIPLE, FBSD_MAJOR, FBSD_CC_VER,
FREEBSD_CC_VERSION, OS_VERSION.
- Update comment in UPDATING regarding debugging options.
- Remove debug.witness.trace=0 from installation media.
- Bump __FreeBSD_version.

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

clang: allow ifunc resolvers to accept arguments

Previously Clang required ifunc resolution functions to take no
arguments, presumably because GCC documented ifunc resolvers as taking
no arguments. However, GCC accepts resolvers accepting arguments, and
our rtld passes CPU ID information (cpuid, hwcap, etc.) to ifunc
resolvers. Just remove the check from the in-tree compiler for our in-
tree compiler; a different (per-OS) approach may be required upstream.

Reported by: mjg
Approved by: re (rgrimes)
MFC after: 1 week
Relnotes: Yes
Sponsored by: The FreeBSD Foundation

Merge llvm, clang, lld, lldb, compiler-rt and libc++ release_70 branch
r339355, resolve conflicts, and bump version numbers.

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.1 release (upstream r335540).

Relnotes: yes
MFC after: 2 weeks

Recommit r332501, with an additional upstream fix for "Cannot lower
EFLAGS copy that lives out of a basic block!" errors on i386.

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Pull in r330264 from upstream llvm trunk (by Chandler Carruth):

[x86] Fix PR37100 by teaching the EFLAGS copy lowering to rewrite
uses across basic blocks in the limited cases where it is very
straight forward to do so.

This will also be useful for other places where we do some limited
EFLAGS propagation across CFG edges and need to handle copy rewrites
afterward. I think this is rapidly approaching the maximum we can and
should be doing here. Everything else begins to require either heroic
analysis to prove how to do PHI insertion manually, or somehow
managing arbitrary PHI-ing of EFLAGS with general PHI insertion.
Neither of these seem at all promising so if those cases come up,
we'll almost certainly need to rewrite the parts of LLVM that produce
those patterns.

We do now require dominator trees in order to reliably diagnose
patterns that would require PHI nodes. This is a bit unfortunate but
it seems better than the completely mysterious crash we would get
otherwise.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Revert r332501 for now, as it can cause build failures on i386.
Reported upstream as <https://bugs.llvm.org/show_bug.cgi?id=37133>.

Reported by: emaste, ci.freebsd.org
PR: 225330

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
6.0.0 release (upstream r326565).

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

Relnotes: yes
MFC after: 3 months
X-MFC-With: r327952
PR: 224669

Bump clang's __FreeBSD_cc_version, to cope with r328816, which removed
-Wno-error=tautological-constant-compare again (this flag is now out of
-Wextra after upstream https://reviews.llvm.org/rL322901). Otherwise
the MK_SYSTEM_COMPILER logic will not build a cross-tools compiler.

Reported by: jpaetzel, tuexen, Stefan Hagen

Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko):

Allow usage of X86-prefixes as separate instrs.
Differential Revision: https://reviews.llvm.org/D42102

This should fix parse errors when x86 prefixes (such as 'lock' and
'rep') are followed by various non-mnemonic tokens, e.g. comments, .byte
directives and labels.

PR: 224669,225054

Bump FREEBSD_CC_VERSION.

Initial update of clang/llvm build glue, for building just a minimal
clang executable.

Bump FREEBSD_CC_VERSION to force bootstrap compiler build.

Merge ^/head r309170 through r309212.

Bump FREEBSD_CC_VERSION again for r309147 and 309149.

In preparation for merging back to head, bump __FreeBSD_version,
FREEBSD_CC_VERSION and set date in ObsoleteFiles.inc.

Pull in r265122 from upstream llvm trunk (by James Molloy):

Fix for pr24346: arm asm label calculation error in sub

Some ARM instructions encode 32-bit immediates as a 8-bit integer
(0-255) and a 4-bit rotation (0-30, even) in its least significant 12
bits. The original fixup, FK_Data_4, patches the instruction by the
value bit-to-bit, regardless of the encoding. For example, assuming
the label L1 and L2 are 0x0 and 0x104 respectively, the following
instruction:

add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260

would be assembled to the following, which adds 1 to r0, instead of
260:

e2800104 add r0, r0, #4, 2 ; equivalently 1

The new fixup kind fixup_arm_mod_imm takes care of the encoding:

e2800f41 add r0, r0, #260

Patch by Ting-Yuan Huang!

This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.

Requested by: jkim
MFC after: 3 days

Pull in r262772 from upstream clang trunk (by Simon Pilgrim):

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

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

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

This ensures clang does not emit AVX instructions for CPUTYPE=btver1.

Reported by: Michel Depeige <demik+freebsd@lostwave.net>
PR: 211864
MFC after: 3 days

Bump FREEBSD_CC_VERSION in lib/clang/freebsd_cc_version.h

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

For clang, move the definition of FREEBSD_CC_VERSION into its own header
file, lib/clang/freebsd_cc_version.h, instead of reusing Version.inc.
The header is only included from one .cpp file in the clang tree.

This minimizes the number of .cpp files that need to be rebuilt if the
version is bumped.

Discussed with: bdrewery

Bump CURRENT to 14.0

This one goes to 14.

Approved by: re (implicit)
Sponsored by: Rubicon Communications, LLC ("Netgate")

* Bump version numbers to 10.0.0
* Update UPDATING
* Update (Optional)ObsoleteFiles.inc
* Update VCS(Revision|Version) files
* Update generated config headers
* Update clang internal headers Makefile

Prepare for merging back to head:
* Set tentative merge date
* Add UPDATING entry
* Bump __FreeBSD_version
* Bump FREEBSD_CC_VERSION
* Bump LLD_REVISION

Pull in r352607 from upstream llvm trunk (by Craig Topper):

[X86] Add FPSW as a Def on some FP instructions that were missing it.

Pull in r353141 from upstream llvm trunk (by Craig Topper):

[X86] Connect the default fpsr and dirflag clobbers in inline
assembly to the registers we have defined for them.

Summary:
We don't currently map these constraints to physical register numbers
so they don't make it to the MachineIR representation of inline
assembly.

This could have problems for proper dependency tracking in the
machine schedulers though I don't have a test case that shows that.

Reviewers: rnk

Reviewed By: rnk

Subscribers: eraman, llvm-commits

Tags: #llvm

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

Pull in r353489 from upstream llvm trunk (by Craig Topper):

[X86] Add FPCW as a register and start using it as an implicit use on
floating point instructions.

Summary:
FPCW contains the rounding mode control which we manipulate to
implement fp to integer conversion by changing the roudning mode,
storing the value to the stack, and then changing the rounding mode
back. Because we didn't model FPCW and its dependency chain, other
instructions could be scheduled into the middle of the sequence.

This patch introduces the register and adds it as an implciit def of
FLDCW and implicit use of the FP binary arithmetic instructions and
store instructions. There are more instructions that need to be
updated, but this is a good start. I believe this fixes at least the
reduced test case from PR40529.

Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor

Subscribers: dim, llvm-commits

Tags: #llvm

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

These should fix a problem in clang 7.0 where it would sometimes emit
long double floating point instructions in a slightly wrong order,
leading to failures in our libm tests. In particular, the cbrt_test
test case 'cbrtl_powl' and the trig_test test case 'reduction'.

Also bump __FreeBSD_cc_version, to be able to detect this in our test
suite.

Reported by: lwhsu
PR: 234040
Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40206
MFC after: 1 week

Update version numbers, and regenerate config headers for llvm, clang,
lld and lldb. Update ObsoleteFiles.inc and OptionalObsoleteFiles.inc.

- Update head to 13.0-CURRENT.
- Bump MACHINE_TRIPLE, TARGET_TRIPLE, FBSD_MAJOR, FBSD_CC_VER,
FREEBSD_CC_VERSION, OS_VERSION.
- Update comment in UPDATING regarding debugging options.
- Remove debug.witness.trace=0 from installation media.
- Bump __FreeBSD_version.

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

clang: allow ifunc resolvers to accept arguments

Previously Clang required ifunc resolution functions to take no
arguments, presumably because GCC documented ifunc resolvers as taking
no arguments. However, GCC accepts resolvers accepting arguments, and
our rtld passes CPU ID information (cpuid, hwcap, etc.) to ifunc
resolvers. Just remove the check from the in-tree compiler for our in-
tree compiler; a different (per-OS) approach may be required upstream.

Reported by: mjg
Approved by: re (rgrimes)
MFC after: 1 week
Relnotes: Yes
Sponsored by: The FreeBSD Foundation

Recommit r332501, with an additional upstream fix for "Cannot lower
EFLAGS copy that lives out of a basic block!" errors on i386.

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Pull in r330264 from upstream llvm trunk (by Chandler Carruth):

[x86] Fix PR37100 by teaching the EFLAGS copy lowering to rewrite
uses across basic blocks in the limited cases where it is very
straight forward to do so.

This will also be useful for other places where we do some limited
EFLAGS propagation across CFG edges and need to handle copy rewrites
afterward. I think this is rapidly approaching the maximum we can and
should be doing here. Everything else begins to require either heroic
analysis to prove how to do PHI insertion manually, or somehow
managing arbitrary PHI-ing of EFLAGS with general PHI insertion.
Neither of these seem at all promising so if those cases come up,
we'll almost certainly need to rewrite the parts of LLVM that produce
those patterns.

We do now require dominator trees in order to reliably diagnose
patterns that would require PHI nodes. This is a bit unfortunate but
it seems better than the completely mysterious crash we would get
otherwise.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Revert r332501 for now, as it can cause build failures on i386.
Reported upstream as <https://bugs.llvm.org/show_bug.cgi?id=37133>.

Reported by: emaste, ci.freebsd.org
PR: 225330

Pull in r325446 from upstream clang trunk (by me):

[X86] Add 'sahf' CPU feature to frontend

Summary:
Make clang accept `-msahf` (and `-mno-sahf`) flags to activate the
`+sahf` feature for the backend, for bug 36028 (Incorrect use of
pushf/popf enables/disables interrupts on amd64 kernels). This was
originally submitted in bug 36037 by Jonathan Looney
<jonlooney@gmail.com>.

As described there, GCC also uses `-msahf` for this feature, and the
backend already recognizes the `+sahf` feature. All that is needed is
to teach clang to pass this on to the backend.

The mapping of feature support onto CPUs may not be complete; rather,
it was chosen to match LLVM's idea of which CPUs support this feature
(see lib/Target/X86/X86.td).

I also updated the affected test case (CodeGen/attr-target-x86.c) to
match the emitted output.

Reviewers: craig.topper, coby, efriedma, rsmith

Reviewed By: craig.topper

Subscribers: emaste, cfe-commits

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

Pull in r328944 from upstream llvm trunk (by Chandler Carruth):

[x86] Expose more of the condition conversion routines in the public
API for X86's instruction information. I've now got a second patch
under review that needs these same APIs. This bit is nicely
orthogonal and obvious, so landing it. NFC.

Pull in r329414 from upstream llvm trunk (by Craig Topper):

[X86] Merge itineraries for CLC, CMC, and STC.

These are very simple flag setting instructions that appear to only
be a single uop. They're unlikely to need this separation.

Pull in r329657 from upstream llvm trunk (by Chandler Carruth):

[x86] Introduce a pass to begin more systematically fixing PR36028
and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the
necessary state in a GPR. In the vast majority of cases, these uses
are cmovCC and jCC instructions. For such cases, we can very easily
save and restore the necessary information by simply inserting a
setCC into a GPR where the original flags are live, and then testing
that GPR directly to feed the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the
flags. This patch handles the vast majority of cases that seem to
come up in practice: adc, adcx, adox, rcl, and rcr; all without
taking advantage of partially preserved EFLAGS as LLVM doesn't
currently model that at all.

There are a large number of operations that techinaclly observe
EFLAGS currently but shouldn't in this case -- they typically are
using DF. Currently, they will not be handled by this approach.
However, I have never seen this issue come up in practice. It is
already pretty rare to have these patterns come up in practical code
with LLVM. I had to resort to writing MIR tests to cover most of the
logic in this pass already. I suspect even with its current amount
of coverage of arithmetic users of EFLAGS it will be a significant
improvement over the current use of pushf/popf. It will also produce
substantially faster code in most of the common patterns.

This patch also removes all of the old lowering for EFLAGS copies,
and the hack that forced us to use a frame pointer when EFLAGS copies
were found anywhere in a function so that the dynamic stack
adjustment wasn't a problem. None of this is needed as we now lower
all of these copies directly in MI and without require stack
adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things
tripping me up while working on this.

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

Pull in r329673 from upstream llvm trunk (by Chandler Carruth):

[x86] Model the direction flag (DF) separately from the rest of
EFLAGS.

This cleans up a number of operations that only claimed te use EFLAGS
due to using DF. But no instructions which we think of us setting
EFLAGS actually modify DF (other than things like popf) and so this
needlessly creates uses of EFLAGS that aren't really there.

In fact, DF is so restrictive it is pretty easy to model. Only STD,
CLD, and the whole-flags writes (WRFLAGS and POPF) need to model
this.

I've also somewhat cleaned up some of the flag management instruction
definitions to be in the correct .td file.

Adding this extra register also uncovered a failure to use the
correct datatype to hold X86 registers, and I've corrected that as
necessary here.

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

Together, these should ensure clang does not use pushf/popf sequences to
save and restore flags, avoiding problems with unrelated flags (such as
the interrupt flag) being restored unexpectedly.

Requested by: jtl
PR: 225330
MFC after: 1 week

Bump clang's __FreeBSD_cc_version, to cope with r328816, which removed
-Wno-error=tautological-constant-compare again (this flag is now out of
-Wextra after upstream https://reviews.llvm.org/rL322901). Otherwise
the MK_SYSTEM_COMPILER logic will not build a cross-tools compiler.

Reported by: jpaetzel, tuexen, Stefan Hagen

Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko):

Allow usage of X86-prefixes as separate instrs.
Differential Revision: https://reviews.llvm.org/D42102

This should fix parse errors when x86 prefixes (such as 'lock' and
'rep') are followed by various non-mnemonic tokens, e.g. comments, .byte
directives and labels.

PR: 224669,225054

Bump FREEBSD_CC_VERSION.

Initial update of clang/llvm build glue, for building just a minimal
clang executable.

Bump FREEBSD_CC_VERSION to force bootstrap compiler build.

Bump FREEBSD_CC_VERSION again for r309147 and 309149.

In preparation for merging back to head, bump __FreeBSD_version,
FREEBSD_CC_VERSION and set date in ObsoleteFiles.inc.

Pull in r265122 from upstream llvm trunk (by James Molloy):

Fix for pr24346: arm asm label calculation error in sub

Some ARM instructions encode 32-bit immediates as a 8-bit integer
(0-255) and a 4-bit rotation (0-30, even) in its least significant 12
bits. The original fixup, FK_Data_4, patches the instruction by the
value bit-to-bit, regardless of the encoding. For example, assuming
the label L1 and L2 are 0x0 and 0x104 respectively, the following
instruction:

add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260

would be assembled to the following, which adds 1 to r0, instead of
260:

e2800104 add r0, r0, #4, 2 ; equivalently 1

The new fixup kind fixup_arm_mod_imm takes care of the encoding:

e2800f41 add r0, r0, #260

Patch by Ting-Yuan Huang!

This fixes label calculation for ARM assembly, and is needed to enable
ARM assembly sources for OpenSSL.

Requested by: jkim
MFC after: 3 days

Pull in r262772 from upstream clang trunk (by Simon Pilgrim):

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

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

[X86] AMD Bobcat CPU (btver1) doesn't support XSAVE

btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't
support XSAVE.

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

This ensures clang does not emit AVX instructions for CPUTYPE=btver1.

Reported by: Michel Depeige <demik+freebsd@lostwave.net>
PR: 211864
MFC after: 3 days

Bump FREEBSD_CC_VERSION in lib/clang/freebsd_cc_version.h

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

For clang, move the definition of FREEBSD_CC_VERSION into its own header
file, lib/clang/freebsd_cc_version.h, instead of reusing Version.inc.
The header is only included from one .cpp file in the clang tree.

This minimizes the number of .cpp files that need to be rebuilt if the
version is bumped.

Discussed with: bdrewery