summaryrefslogtreecommitdiffstats
path: root/gnu/llvm/lib/Target/PowerPC/PPCISelLowering.cpp (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove LLVM 8.0.1 files.patrick2020-08-031-14764/+0
|
* Set max atomic size for PowerPC.gkoehler2020-06-041-1/+4
| | | | | | | | | | | | 32-bit PowerPC doesn't have instructions for lock-free atomic ops on 8-byte values, and needs libcalls like __atomic_fetch_add_8(). In code like "_Atomic long long a; a++;", clang doesn't emit a libcall. This was causing linker errors on symbols like __sync_fetch_and_add_8. Now that LLVM knows the max atomic size, its AtomicExpandPass changes these 8-byte ops into libcalls. ok mortimer@
* Merge LLVM 8.0.0 release.patrick2019-06-231-237/+804
| | | | | | | | | Prepared with help from jsg@ and mortimer@ Tested on amd64 by bcallah@, krw@, naddy@ Tested on arm64 by patrick@ Tested on macppc by kettenis@ Tested on octeon by visa@ Tested on sparc64 by claudio@
* When generating code for OpenBSD/powerpc, avoid unaligned floating-pointkettenis2019-02-181-0/+8
| | | | | | | | | | | | load and store instructions. The vast majority of PowerPC CPUs that OpenBSD runs on don't implement those and will generate an alignment exceptions. While we do emulate lfd and stfd (to work around GCC bugs), we don't emulate lfs and stfs. It is way more efficient to have the compiler generate code that only uses aligned load and store instructions. Based on a diff from Georg Koehler. ok patrick@, visa@
* Import LLVM 7.0.1 release including clang, lld and lldb.patrick2019-01-271-191/+456
|
* Import LLVM 6.0.1 release including clang, lld and lldb.patrick2018-04-061-82/+534
| | | | "where is the kaboom?" deraadt@
* Import LLVM 5.0.0 release including clang, lld and lldb.patrick2017-10-041-230/+929
|
* Import LLVM 4.0.0 rc1 including clang and lld to help the currentpatrick2017-01-241-215/+771
| | | | development effort on OpenBSD/arm64.
* Import LLVM 3.9.1 including clang and lld.patrick2017-01-141-809/+1415
|
* Use the space freed up by sparc and zaurus to import LLVM.pascal2016-09-031-0/+11608
ok hackroom@