Merge clang 7.0.1 and several follow-up changes

MFC r341825:

Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
the upstream release_70 branch r348686 (effectively, 7.0.1 rc3).

Merge clang 7.0.1 and several follow-up changes

MFC r341825:

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

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

PR: 230240, 230355
Relnotes: yes

MFC r342123:

Update clang, llvm, lld, lldb, compiler-rt and libc++ version number to
7.0.1 release r349250. There were no functional changes since the 7.0.1
rc3 import.

PR: 230240, 230355
Relnotes: yes

r343429 | emaste | 2019-01-25 15:46:13 +0100 (Fri, 25 Jan 2019) | 16 lines

clang: default to DWARF 4 as of FreeBSD 13

FreeBSD previously defaulted to DWARF 2 because several tools (gdb,
ctfconvert, etc.) did not support later versions. These have either
been fixed or are deprecated.

Note that gdb 6 still exists but has been moved out of $PATH into
/usr/libexec and is intended only for use by crashinfo(8). The kernel
build sets the DWARF version explicitly via -gdwarf2, so this should
have no effect there.

PR: 234887 [exp-run]
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17930

MFC r343916:

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

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

[ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly.

Intentionally excluding nodes from the DAGCombine worklist is likely
to lead to weird optimizations and infinite loops, so it's generally
a bad idea.

To avoid the infinite loops, fix DAGCombine to use the
isDesirableToCommuteWithShift target hook before performing the
transforms in question, and implement the target hook in the ARM
backend disable the transforms in question.

Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a
reduced testcase for that bug. But we should have sufficient test
coverage for PerformSHLSimplify given that we're not playing weird
tricks with the worklist. I can try to bugpoint it if necessary,
though.)

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

This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c
(which exists now only in the stable/11 branch) for arm.

show more ...

Pull in r221703 from upstream llvm trunk (by Bill Schmidt):

[PowerPC] Replace foul hackery with real calls to __tls_get_addr

My original support for the general dynamic and local dynamic TLS

Pull in r221703 from upstream llvm trunk (by Bill Schmidt):

[PowerPC] Replace foul hackery with real calls to __tls_get_addr

My original support for the general dynamic and local dynamic TLS
models contained some fairly obtuse hacks to generate calls to
__tls_get_addr when lowering a TargetGlobalAddress. Rather than
generating real calls, special GET_TLS_ADDR nodes were used to wrap
the calls and only reveal them at assembly time. I attempted to
provide correct parameter and return values by chaining CopyToReg and
CopyFromReg nodes onto the GET_TLS_ADDR nodes, but this was also not
fully correct. Problems were seen with two back-to-back stores to TLS
variables, where the call sequences ended up overlapping with unhappy
results. Additionally, since these weren't real calls, the proper
register side effects of a call were not recorded, so clobbered values
were kept live across the calls.

The proper thing to do is to lower these into calls in the first
place. This is relatively straightforward; see the changes to
PPCTargetLowering::LowerGlobalTLSAddress() in PPCISelLowering.cpp.
The changes here are standard call lowering, except that we need to
track the fact that these calls will require a relocation. This is
done by adding a machine operand flag of MO_TLSLD or MO_TLSGD to the
TargetGlobalAddress operand that appears earlier in the sequence.

The calls to LowerCallTo() eventually find their way to
LowerCall_64SVR4() or LowerCall_32SVR4(), which call FinishCall(),
which calls PrepareCall(). In PrepareCall(), we detect the calls to
__tls_get_addr and immediately snag the TargetGlobalTLSAddress with
the annotated relocation information. This becomes an extra operand
on the call following the callee, which is expected for nodes of type
tlscall. We change the call opcode to CALL_TLS for this case. Back
in FinishCall(), we change it again to CALL_NOP_TLS for 64-bit only,
since we require a TOC-restore nop following the call for the 64-bit
ABIs.

During selection, patterns in PPCInstrInfo.td and PPCInstr64Bit.td
convert the CALL_TLS nodes into BL_TLS nodes, and convert the
CALL_NOP_TLS nodes into BL8_NOP_TLS nodes. This replaces the code
removed from PPCAsmPrinter.cpp, as the BL_TLS or BL8_NOP_TLS
nodes can now be emitted normally using their patterns and the
associated printTLSCall print method.

Finally, as a result of these changes, all references to get-tls-addr
in its various guises are no longer used, so they have been removed.

There are existing TLS tests to verify the changes haven't messed
anything up). I've added one new test that verifies that the problem
with the original code has been fixed.

This fixes a fatal "Bad machine code" error when compiling parts of
libgomp for 32-bit PowerPC.

show more ...

Backport r197824, r213427 and r213960 from LLVM trunk:

r197824 | rdivacky | 2013-12-20 19:08:54 +0100 (Fri, 20 Dec 2013) | 2 lines

Implement initial-exec TLS for PPC32.

r213427 | hfinkel | 2

Backport r197824, r213427 and r213960 from LLVM trunk:

r197824 | rdivacky | 2013-12-20 19:08:54 +0100 (Fri, 20 Dec 2013) | 2 lines

Implement initial-exec TLS for PPC32.

r213427 | hfinkel | 2014-07-19 01:29:49 +0200 (Sat, 19 Jul 2014) | 7 lines

[PowerPC] 32-bit ELF PIC support

This adds initial support for PPC32 ELF PIC (Position Independent Code; the
-fPIC variety), thus rectifying a long-standing deficiency in the PowerPC
backend.

Patch by Justin Hibbits!

r213960 | hfinkel | 2014-07-25 19:47:22 +0200 (Fri, 25 Jul 2014) | 3 lines

[PowerPC] Support TLS on PPC32/ELF

Patch by Justin Hibbits!

Reviewed by: jhibbits
Approved by: dim

show more ...