370036 |
25-Jun-2021 |
dim |
Disable llvm generating 128-bit multiply libcalls on 32-bit ARM
Merge commit 789708617d20 from llvm git (Koutheir Attouchi):
Do not generate calls to the 128-bit function __multi3() on 32-bit ARM
Re-applying this patch after bots failures. Should be fine now.
The function __multi3() is undefined on 32-bit ARM, so a call to it should never be emitted. Instead, plain instructions need to be generated to perform 128-bit multiplications.
Differential Revision: https://reviews.llvm.org/D103906
Reported by: mmel
(cherry picked from commit 014a40f8f643a5dad6a6ba5c4bf6ea5d4f445fe6)
Git Hash: a35615900cf525d1b4318837ccd4ce32fdf0fe5c Git Author: dim@FreeBSD.org |
368974 |
08-Jan-2021 |
dim |
MFC llvm fixes for building ceph on powerpc
Merge commit 8f5e3c74b from llvm git (by Teresa Johnson):
[PowerPC] Fix compile time issue in recursive CTR analysis code
Summary: Avoid re-examining operands on recursive walk looking for CTR. This was causing huge compile time after some earlier optimization created a large expression.
The start of the expression (created by IndVarSimplify) looked like:
%469 = lshr i64 trunc (i128 xor (i128 udiv (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 ptrtoint (i8 @_ZN4absl13hash_internal13CityHashState5kSeedE to i64), i64 120) to i128), i128 8192506886679785011), i128 64), i128 mul (i128 zext (i64 add (i64 ptrtoint (i8 @_ZN4absl13hash_internal13CityHashState5kSeedE to i64), i64 120) to i128), i128 8192506886679785011)) to i64), i64 45) to i128), i128 8192506886679785011), i128 64), i128 mul (i128 zext (i64 add (i64 trunc (i128 xor (i128 lshr (i128 mul (i128 zext (i64 add (i64 ptrtoint (i8 @_ZN4absl13hash_internal13CityHashState5kSeedE to i64), i64 120) to i128), i128 8192506886679785011), i128 64), i128 mul (i128 zext (i64 add (i64 ptrtoint (i8 @_ZN4absl13hash_internal13CityHashState5kSeedE to i64), i64 120) to i128), i128 8192506886679785011)) to i64), i64 45) to i128), ...
with the _ZN4absl13hash_internal13CityHashState5kSeedE referenced many times.
Reviewers: hfinkel
Subscribers: nemanjai, hiraditya, kbarton, jsji, shchenz, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75790
Merge commit 4f568fbd2 from llvm git (by Nemanja Ivanovic):
[PowerPC] Do not emit HW loop when TLS var accessed in PHI of loop exit
If any PHI nodes in loop exit blocks have incoming values from the loop that are accesses of TLS variables with local dynamic or general dynamic TLS model, the address will be computed inside the loop. Since this includes a call to __tls_get_addr, this will in turn cause the CTR loops verifier to complain. Disable CTR loops in such cases.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=48527
This should fix building ceph 12.2.12 on powerpc64, powerpc, powerpcspe and powerpc64le.
Requested by: pkubaj
(cherry picked from commit 543478be758fdfbf050eca5b58b7c74ba51b9175)
Git Hash: 15b3e1e51cb59f69e3971e6c4ad010d27325a2d9 Git Author: dim@FreeBSD.org |
367603 |
11-Nov-2020 |
dim |
MFC r367485:
Merge commit 354d3106c from llvm git (by Kai Luo):
[PowerPC] Skip combining (uint_to_fp x) if x is not simple type
Current powerpc64le backend hits ``` Combining: t7: f64 = uint_to_fp t6 llc: llvm-project/llvm/include/llvm/CodeGen/ValueTypes.h:291: llvm::MVT llvm::EVT::getSimpleVT() const: Assertion `isSimple() && "Expected a SimpleValueType!"' failed. ``` This patch fixes it by skipping combination if `t6` is not simple type. Fixed https://bugs.llvm.org/show_bug.cgi?id=47660.
Reviewed By: #powerpc, steven.zhang
Differential Revision: https://reviews.llvm.org/D88388
This should fix the llvm assertion mentioned above when building the following ports for powerpc64le:
* audio/traverso * databases/percona57-pam-for-mysql * databases/percona57-server * emulators/citra * emulators/citra-qt5 * games/7kaa * graphics/dia * graphics/mandelbulber * graphics/pcl-pointclouds * net-p2p/libtorrent-rasterbar * textproc/htmldoc
Requested by: pkubaj |
366452 |
05-Oct-2020 |
dim |
Merge commit 0fac1c191 from llvm git (by Craig Topper):
[X86] Allow Yz inline assembly constraint to choose ymm0 or zmm0 when avx/avx512 are enabled and type is 256 or 512 bits
gcc supports selecting ymm0/zmm0 for the Yz constraint when used with 256 or 512 bit vector types.
Fixes PR45806
Differential Revision: https://reviews.llvm.org/D79448
This should fix 'fatal error: error in backend: Cannot select' errors if assertions are disabled, or 'Assertion failed: (isVector() && "Invalid vector type!"), function getVectorNumElements, file /usr/src/contrib/llvm-project/llvm/include/llvm/CodeGen/ValueTypes.h, line 276.', when building the audio/lsp-plugins-lv2 port.
Direct commit to stable/{11,12} since head has clang 11.0.0, which already includes this fix.
Reported by: yuri PR: 232911 |
363496 |
24-Jul-2020 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).
MFC r360702:
Merge commit 4ca2cad94 from llvm git (by Justin Hibbits):
[PowerPC] Add clang -msvr4-struct-return for 32-bit ELF
Summary:
Change the default ABI to be compatible with GCC. For 32-bit ELF targets other than Linux, Clang now returns small structs in registers r3/r4. This affects FreeBSD, NetBSD, OpenBSD. There is no change for 32-bit Linux, where Clang continues to return all structs in memory.
Add clang options -maix-struct-return (to return structs in memory) and -msvr4-struct-return (to return structs in registers) to be compatible with gcc. These options are only for PPC32; reject them on PPC64 and other targets. The options are like -fpcc-struct-return and -freg-struct-return for X86_32, and use similar code.
To actually return a struct in registers, coerce it to an integer of the same size. LLVM may optimize the code to remove unnecessary accesses to memory, and will return i32 in r3 or i64 in r3:r4.
Fixes PR#40736
Patch by George Koehler!
Reviewed By: jhibbits, nemanjai Differential Revision: https://reviews.llvm.org/D73290
Requested by: jhibbits
MFC r361410:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.1-rc1-0-gf79cd71e145 (aka 10.0.1 rc1).
MFC r362235 (by kp):
llvm: Default to -mno-relax on RISC-V
Compiling on a RISC-V system fails with 'relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax'.
Our default linker (ld.lld) doesn't support relaxation, so default to no-relax so we don't generate object files the linker can't handle.
Reviewed by: mhorne Sponsored by: Axiado Differential Revision: https://reviews.freebsd.org/D25210
MFC r362445:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-97-g6f71678ecd2 (not quite 10.0.1 rc2, as more fixes are still pending).
MFC r362587 (by cem):
Add WITH_CLANG_FORMAT option
clang-format is enabled conditional on either WITH_CLANG_EXTRAS or WITH_CLANG_FORMAT. Some sources in libclang are build conditional on either rule, and obviously the clang-format binary itself depends on the rule.
clang-format could still use a manual page.
Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D25427
MFC r362609:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-129-gd24d5c8e308. Getting closer to 10.0.1-rc2.
MFC r362679:
Regenerate ReStructuredText based manpages for llvm-project tools:
* bugpoint.1 * clang.1 * llc.1 * lldb.1 * lli.1 * llvm-ar.1 * llvm-as.1 * llvm-bcanalyzer.1 * llvm-cov.1 * llvm-diff.1 * llvm-dis.1 * llvm-dwarfdump.1 * llvm-extract.1 * llvm-link.1 * llvm-mca.1 * llvm-nm.1 * llvm-pdbutil.1 * llvm-profdata.1 * llvm-symbolizer.1 * llvm-tblgen.1 * opt.1
Add newly generated manpages for:
* llvm-addr2line.1 (this is an alias of llvm-symbolizer) * llvm-cxxfilt.1 * llvm-objcopy.1 * llvm-ranlib.1 (this is an alias of llvm-ar)
Note that llvm-objdump.1 is an exception, as upstream has both a plain .1 file, and a .rst variant. These will have to be reconciled upstream first.
MFC r362680:
Follow-up to r362679, add more entries to OptionalObsoleteFiles.inc
MFC r362719:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.1-rc2-0-g77d76b71d7d.
Also add a few more llvm utilities under WITH_CLANG_EXTRAS:
* llvm-dwp, a utility for merging DWARF 5 Split DWARF .dwo files into .dwp (DWARF package files) * llvm-size, a size(1) replacement * llvm-strings, a strings(1) replacement
MFC r362733:
Remove older llvm-ranlib.1 entry from ObsoleteFiles.inc, as it has gotten its own manpage now, and should be no longer be removed by "make delete-old".
MFC r362734:
Fix llvm-strings.1 not installing, this was a copy/paste error.
MFC r363401:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).
There were no changes since rc2, except in the upstream regression tests, which we do not ship.
Relnotes: yes |
362461 |
21-Jun-2020 |
dim |
MFC r362341:
Merge commit 0cecafd647cc from llvm git (by Alina Sbirlea):
[BasicAA] Make BasicAA a cfg pass.
Summary: Part of the changes in D44564 made BasicAA not CFG only due to it using PhiAnalysisValues which may have values invalidated. Subsequent patches (rL340613) appear to have addressed this limitation.
BasicAA should not be invalidated by non-CFG-altering passes. A concrete example is MemCpyOpt which preserves CFG, but we are testing it invalidates BasicAA.
llvm-dev RFC: https://groups.google.com/forum/#!topic/llvm-dev/eSPXuWnNfzM
Reviewers: john.brawn, sebpop, hfinkel, brzycki
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74353
This fixes an issue with clang's -fintegrated-cc1 feature, which could make it output slightly different assembly code, depending on the way it was invoked.
In r361755 we attempted to work around it by disabling the integrated cc1 stage, but it did not solve the root cause for all situations.
Extensive testing and bisecting showed that the above change finally makes the output deterministic, even if -fintegrated-cc1 is on.
Reported by: Fabian Keil <fk@fabiankeil.de> PR: 246630 |
360876 |
10-May-2020 |
emaste |
MFC r360801: Merge commit 21e5e1724b75 from llvm git:
getMainExecutable: Fix hand-rolled AT_EXECPATH for older FreeBSD
Once we hit AT_NULL, we need to bail out of the loop; not just the enclosing switch. This fixes basic usage (e.g. `cc --version`) when AT_EXECPATH isn't present on older branches (e.g. under emu-user-static, at the moment), where we would previously run off the end of ::environ.
Patch By: kevans
Reviewed By: arichardson |
360784 |
07-May-2020 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release), and a number of follow-ups.
MFC r356479 (by bdragon):
[PowerPC] Fix libllvmminimal build when building from powerpc64 ELFv1.
When bootstrapping on powerpc64 ELFv1, it is necessary to use binutils ld.bfd from ports for the bootstrap, as this is the only modern linker for ELFv1 host tools.
As binutils ld.bfd is rather strict in its handling of undefined symbols, it is necessary to pull in Support/Atomic.cpp to avoid an undefined symbol.
Reviewed by: dim, emaste Sponsored by: Tag1 Consulting, Inc. Differential Revision: https://reviews.freebsd.org/D23072
MFC r356930:
Add more Subversion mergeinfo bootstrap information, to hopefully increase the probability of merging in vendor changes.
MFC r358408 (by brooks):
Merge commit 7214f7a79 from llvm git (by Sam Elliott):
[RISCV] Lower llvm.trap and llvm.debugtrap
Summary: Until this commit, these have lowered to a call to abort().
`llvm.trap()` now lowers to `unimp`, which should trap on all systems.
`llvm.debugtrap()` now lowers to `ebreak`, which is exactly what this instruction is for.
Reviewers: asb, luismarques
Reviewed By: asb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69390
This fixes miscompilation resulting in linking failures with INVARIANTS disabled.
Reviewed by: dim Differential Revision: https://reviews.freebsd.org/D23857
MFC r358851:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 10.0.0-rc3 c290cb61fdc.
Release notes for llvm, clang, lld and libc++ 10.0.0 will become available here:
https://releases.llvm.org/10.0.0/docs/ReleaseNotes.html https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/10.0.0/projects/libcxx/docs/ReleaseNotes.html
PR: 244251
MFC r358854:
Add one additional file to libllvmminimal, to help the ppc64 bootstrap.
Reported by: bdragon PR: 244251
MFC r358857:
Move another file in libllvm from sources required for world, to sources required for bootstrap, as the PowerPC builds need this.
Reported by: bdragon PR: 244251
MFC r359082:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real Soon Now.
PR: 244251
MFC r359084:
Merge commit 00925aadb from llvm git (by Fangrui Song):
[ELF][PPC32] Fix canonical PLTs when the order does not match the PLT order
Reviewed By: Bdragon28
Differential Revision: https://reviews.llvm.org/D75394
This is needed to fix miscompiled canonical PLTs on ppc32/lld10.
Requested by: bdragon Differential Revision: https://reviews.freebsd.org/D24109
MFC r359085:
Merge commit 315f8a55f from llvm git (by Fangrui Song):
[ELF][PPC32] Don't report "relocation refers to a discarded section" for .got2
Similar to D63182 [ELF][PPC64] Don't report "relocation refers to a discarded section" for .toc
Reviewed By: Bdragon28
Differential Revision: https://reviews.llvm.org/D75419
This is needed to fix compile errors when building for ppc32/lld10.
Requested by: bdragon Differential Revision: https://reviews.freebsd.org/D24110
MFC r359086:
Merge commit b8ebc11f0 from llvm git (by Sanjay Patel):
[EarlyCSE] avoid crashing when detecting min/max/abs patterns (PR41083)
As discussed in PR41083: https://bugs.llvm.org/show_bug.cgi?id=41083 ...we can assert/crash in EarlyCSE using the current hashing scheme and instructions with flags.
ValueTracking's matchSelectPattern() may rely on overflow (nsw, etc) or other flags when detecting patterns such as min/max/abs composed of compare+select. But the value numbering / hashing mechanism used by EarlyCSE intersects those flags to allow more CSE.
Several alternatives to solve this are discussed in the bug report. This patch avoids the issue by doing simple matching of min/max/abs patterns that never requires instruction flags. We give up some CSE power because of that, but that is not expected to result in much actual performance difference because InstCombine will canonicalize these patterns when possible. It even has this comment for abs/nabs:
/// Canonicalize all these variants to 1 pattern. /// This makes CSE more likely.
(And this patch adds PhaseOrdering tests to verify that the expected transforms are still happening in the standard optimization pipelines.
I left this code to use ValueTracking's "flavor" enum values, so we don't have to change the callers' code. If we decide to go back to using the ValueTracking call (by changing the hashing algorithm instead), it should be obvious how to replace this chunk.
Differential Revision: https://reviews.llvm.org/D74285
This fixes an assertion when building the math/gsl port on PowerPC64.
Requested by: pkubja
MFC r359087:
Merge commit 585a3cc31 from llvm git (by me):
Fix -Wdeprecated-copy-dtor and -Wdeprecated-dynamic-exception-spec warnings.
Summary: The former are like:
libcxx/include/typeinfo:322:11: warning: definition of implicit copy constructor for 'bad_cast' is deprecated because it has a user-declared destructor [-Wdeprecated-copy-dtor] virtual ~bad_cast() _NOEXCEPT; ^ libcxx/include/typeinfo:344:11: note: in implicit copy constructor for 'std::bad_cast' first required here throw bad_cast(); ^
Fix these by adding an explicitly defaulted copy constructor.
The latter are like:
libcxx/include/codecvt:105:37: warning: dynamic exception specifications are deprecated [-Wdeprecated-dynamic-exception-spec] virtual int do_encoding() const throw(); ^~~~~~~
Fix these by using the _NOEXCEPT macro instead.
Reviewers: EricWF, mclow.lists, ldionne, #libc
Reviewed By: EricWF, #libc
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76150
This is because we use -Wsystem-headers during buildworld, and the two warnings above are now triggered by default with clang 10, preventing most C++ code from compiling without NO_WERROR.
Requested by: brooks Differential Revision: https://reviews.freebsd.org/D24049
MFC r359333:
Merge commit f0990e104 from llvm git (by Justin Hibbits):
[PowerPC]: e500 target can't use lwsync, use msync instead
The e500 core has a silicon bug that triggers an illegal instruction program trap on any sync other than msync. Other cores will typically ignore illegal sync types, and the documentation even implies that the 'illegal' bits are ignored.
Address this hardware deficiency by only using msync, like the PPC440.
Differential Revision: https://reviews.llvm.org/D76614
Requested by: jhibbits
MFC r359334:
Merge commit 459e8e948 from llvm git (by Justin Hibbits):
[PowerPC]: Don't allow r0 as a target for LD_GOT_TPREL_L/32
Summary: The linker is free to relax this (relocation R_PPC_GOT_TPREL16) against R_PPC_TLS, if it sees fit (initial exec to local exec). If r0 is used, this can generate execution-invalid code (converts to 'addi %rX, %r0, FOO, which translates in PPC-lingo to li %rX, FOO). Forbid this instead.
This fixes static binaries using locales on FreeBSD/powerpc (tested on FreeBSD/powerpcspe).
Reviewed By: nemanjai Differential Revision: https://reviews.llvm.org/D76662
Requested by: jhibbits
MFC r359338:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release).
PR: 244251
MFC r359506 (by emaste):
lldb: stop excluding bindings/ subdir
With liblua in the tree we should be able to enable lldb's lua scripting. We'll need the files in bindings/, so start by allowing them to come in with the next import.
Approved by: dim Sponsored by: The FreeBSD Foundation
MFC r359578:
Merge once more from ^/vendor/llvm-project/release-10.x, to get the lldb/bindings directory, which will be used to provide lua bindings for lldb.
Requested by: emaste
MFC r359826:
Merge commit 30588a739 from llvm git (by Erich Keane):
Make target features check work with ctor and dtor-
The problem was reported in PR45468, applying target features to an always_inline constructor/destructor runs afoul of GlobalDecl construction assert when checking for target-feature compatibility.
The core problem is fixed by using the version of the check that takes a FunctionDecl rather than the GlobalDecl. However, while writing the test, I discovered that source locations weren't properly set for this check on ctors/dtors. This patch also fixes constructors and CALLED destructors.
Unfortunately, it doesn't seem too possible to get a meaningful source location for a 'cleanup' destructor, so those are still 'frontend' level errors unfortunately. A fixme was added to the test to cover that situation.
This should fix 'Assertion failed: (!isa<CXXConstructorDecl>(D) && "Use other ctor with ctor decls!"), function Init, file /usr/src/contrib/llvm-project/clang/include/clang/AST/GlobalDecl.h, line 45' when compiling the security/botan2 port.
PR: 245550
MFC r359981:
Revert commit a9ad65a2b from llvm git (by Nemanja Ivanovic):
[PowerPC] Change default for unaligned FP access for older subtargets
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40554
Some CPU's trap to the kernel on unaligned floating point access and there are kernels that do not handle the interrupt. The program then fails with a SIGBUS according to the PR. This just switches the default for unaligned access to only allow it on recent server CPUs that are known to allow this.
Differential revision: https://reviews.llvm.org/D71954
This upstream commit causes a compiler hang when building certain ports (e.g. security/nss, multimedia/x264) for powerpc64. The hang has been reported in https://bugs.llvm.org/show_bug.cgi?id=45186, but in the mean time it is more convenient to revert the commit.
Requested by: jhibbits
MFC r359994:
Revert commit b6cf400aa fro llvm git (by Nemanja Ivanovic):
Fix bots after a9ad65a2b34f
In the last commit, I neglected to initialize the new subtarget feature I added which caused failures on a few bots. This should fix that.
This unbreaks the build after r359981, which reverted upstream commit a9ad65a2b34f.
Reported by: jhibbits (and jenkins :)
MFC r360129:
Merge commit ce5173c0e from llvm git (by Reid Kleckner):
Use FinishThunk to finish musttail thunks
FinishThunk, and the invariant of setting and then unsetting CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't exist when I added this musttail codepath in ab2090d10765 (2014). Recently in 28328c3771, I started using this codepath on non-Windows platforms, and users reported problems during release testing (PR44987).
The issue was already present for users of EH on i686-windows-msvc, so I added a test for that case as well.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D76444
This should fix 'Assertion failed: (!empty() && "popping exception stack when not empty"), function popTerminate, file /usr/src/contrib/llvm-project/clang/lib/CodeGen/CGCleanup.h, line 583' when building the net-p2p/libtorrent-rasterbar
PR: 244830 Reported by: jbeich, yuri
MFC r360134:
Merge commit 64b31d96d from llvm git (by Nemanja Ivanovic):
[PowerPC] Do not attempt to reuse load for 64-bit FP_TO_UINT without FPCVT
We call the function that attempts to reuse the conversion without checking whether the target matches the constraints that the callee expects. This patch adds the check prior to the call.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=43976
Differential revision: https://reviews.llvm.org/D77564
This should fix 'Assertion failed: ((Op.getOpcode() == ISD::FP_TO_SINT || Subtarget.hasFPCVT()) && "i64 FP_TO_UINT is supported only with FPCVT"), function LowerFP_TO_INTForReuse, file /usr/src/contrib/llvm/lib/Target/PowerPC/PPCISelLowering.cpp, line 7276' when building the devel/libslang2 port (and a few others) for PowerPC64.
Requested by: pkubaj
MFC r360350:
Tentatively apply https://reviews.llvm.org/D78877 (by Dave Green):
[ARM] Only produce qadd8b under hasV6Ops
When compiling for a arm5te cpu from clang, the +dsp attribute is set. This meant we could try and generate qadd8 instructions where we would end up having no pattern. I've changed the condition here to be hasV6Ops && hasDSP, which is what other parts of ARMISelLowering seem to use for similar instructions.
Fixed PR45677.
This fixes "fatal error: error in backend: Cannot select: t37: i32 = ARMISD::QADD8b t43, t44" when compiling sys/dev/sound/pcm/feeder_mixer.c for armv5. For some reason we do not encounter this on head, but this error popped up while building universes for stable/12.
MFC r360697:
In r358396 I merged llvm upstream commit 2e24219d3, which fixed "error: unsupported relocation on symbol" when assembling arm 'adr' pseudo instructions. However, the upstream commit did not take big-endian arm into account.
Applying the same changes to the big-endian handling is straightforward, thanks to Andrew Turner and Peter Smith for the hint. This will also be submitted upstream. |
360661 |
05-May-2020 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05, and a number of follow-ups.
MFC r355948:
Bootstrap mergeinfo for contrib/llvm-project
Merge (record-only) the following paths to contrib/llvm-project: * ^/vendor/llvm-project/master * ^/vendor/llvm-project/release-8.x * ^/vendor/llvm-project/release-9.x
MFC r355951:
Merge empty dir updates from r355950 in vendor/llvm-project.
MFC r355957:
Merge diff elimination updates from r355953 into vendor/llvm-project.
MFC r355959:
Consolidate FREEBSD-Xlist files of different llvm sub-projects into one.
MFC r356004:
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 r356005:
Merge commit f97936fab from llvm git (by Eric Fiselier):
[libc++] Cleanup and enable multiple warnings.
Too many warnings are being disabled too quickly. Warnings are important to keeping libc++ correct. This patch re-enables two warnings: -Wconstant-evaluated and -Wdeprecated-copy.
In future, all warnings disabled for the test suite should require an attached bug. The bug should state the plan for re-enabling that warning, or a strong case why it should remain disabled.
This should fix a number of new g++ 9 warnings.
Requested by: rlibby
MFC r356100:
Merge commit d3aeac8e2 from llvm git (by Justin Hibbits)
[PowerPC] Only use PLT annotations if using PIC relocation model
Summary: The default static (non-PIC, non-PIE) model for 32-bit powerpc does not use @PLT annotations and relocations in GCC. LLVM shouldn't use @PLT annotations either, because it breaks secure-PLT linking with (some versions of?) GNU LD.
Update the available-externally.ll test to reflect that default mode should be the same as the static relocation, by using the same check prefix.
Reviewed by: sfertile Differential Revision: https://reviews.llvm.org/D70570
Reviewed by: jhibbits Differential Revision: https://reviews.freebsd.org/D22913
MFC r356104 (by jhibbits):
[PowerPC] enable atomic.c in compiler_rt and do not check and forces lock/lock_free decisions in compiled time
Summary: Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime decision about lock/lock_free. At compiling time, if clang can't decide if atomic operation can be lock free, it emits calls to external functions like `__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and `__atomic_always_lock_free`, postponing decision to a runtime check. According to LLVM code documentation, the mechanism exists due to differences between x86_64 processors that can't be decided at runtime.
On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock free, so we force the decision at compile time and avoid having to implement it in an external library.
This patch was made after 32 bit users testing the PowePC32 bit ISO reported llvm could not be compiled with in-base llvm due to `__atomic_load8` not implemented.
Submitted by: alfredo.junior_eldorado.org.br Reviewed by: jhibbits, dim
Differential Revision: https://reviews.freebsd.org/D22549
MFC r356112 (by jhibbits):
[PowerPC64] Starting from FreeBSD 13.0, default to ELFv2 ABI
This changes the LLVM default powerpc64 ABI to ELFv2, if target OS is FreeBSD >= 13.0
This will also be sent upstream.
Submitted by: alfredo.junior_eldorado.org.br Reviewed by: dim, luporl Relnotes: YES Differential Revision: https://reviews.freebsd.org/D20383
MFC r356256:
Merge commit 468a0cb5f from llvm git (by Craig Topper):
[X86] Add X87 FCMOV support to X86FlagsCopyLowering.
Fixes PR44396
Merge commit 86f48999f from llvm git (by Craig Topper):
[X86] Fix typo in getCMovOpcode.
The 64-bit HasMemoryOperand line was using CMOV32rm instead of CMOV64rm. Not sure how to test this. We have no test coverage that passes true for HasMemoryOperand.
This fixes 'Assertion failed: (MI.findRegisterDefOperand(X86::EFLAGS) && "Expected a def of EFLAGS for this instruction!"), function runOnMachineFunction' when compiling the misc/gpsim port for i386.
Reported by: yuri Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=44396
MFC r356329:
Merge commit 41449c58c from llvm git (by Roger Ferrer Ibanez):
[RISCV] Fix evaluation of %pcrel_lo
The following testcase
function: .Lpcrel_label1: auipc a0, %pcrel_hi(other_function) addi a1, a0, %pcrel_lo(.Lpcrel_label1) .p2align 2 # Causes a new fragment to be emitted
.type other_function,@function other_function: ret
exposes an odd behaviour in which only the %pcrel_hi relocation is evaluated but not the %pcrel_lo.
$ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump -d -r -
<stdin>: file format ELF64-riscv
Disassembly of section .text: 0000000000000000 function: 0: 17 05 00 00 auipc a0, 0 4: 93 05 05 00 mv a1, a0 0000000000000004: R_RISCV_PCREL_LO12_I other_function+4
0000000000000008 other_function: 8: 67 80 00 00 ret
The reason seems to be that in RISCVAsmBackend::shouldForceRelocation we only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we consider the section. This usually works but there are cases where the section may still be the same but the fragment may be another one. In that case we end forcing a %pcrel_lo relocation without any %pcrel_hi.
This patch makes RISCVAsmBackend::shouldForceRelocation use the section, if any, to determine if the relocation must be forced or not.
Differential Revision: https://reviews.llvm.org/D60657
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356330:
Merge commit da7b129b1 from llvm git (by James Clarke):
[RISCV] Don't force Local Exec TLS for non-PIC
Summary:
Forcing Local Exec TLS requires the use of copy relocations. Copy relocations need special handling in the runtime linker when being used against TLS symbols, which is present in glibc, but not in FreeBSD nor musl, and so cannot be relied upon. Moreover, copy relocations are a hack that embed the size of an object in the ABI when it otherwise wouldn't be, and break protected symbols (which are expected to be DSO local), whilst also wasting space, thus they should be avoided whenever possible. As discussed in D70398, RISC-V should move away from forcing Local Exec, and instead use Initial Exec like other targets, with possible linker relaxation to follow. The RISC-V GCC maintainers also intend to adopt this more-conventional behaviour (see https://github.com/riscv/riscv-elf-psabi-doc/issues/122).
Reviewers: asb, MaskRay
Reviewed By: MaskRay
Subscribers: emaste, krytarowski, hiraditya, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, llvm-commits, bsdjhb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70649
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356331:
?Merge commit c6b09bff5 from llvm git (by Lu?s Marques):
[RISCV] Fix wrong CFI directives
Summary: Removes CFI CFA directives that could incorrectly propagate beyond the basic block they were inteded for. Specifically it removes the epilogue CFI directives. See the branch_and_tail_call test for an example of the issue. Should fix the stack unwinding issues caused by the incorrect directives.
Reviewers: asb, lenary, shiva0217 Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D69723
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356332:
?Merge commit d7be3eab5 from llvm git (by Lu?s Marques):
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32)
Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF.
Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356333:
?Merge commit 189b7393d from llvm git (by John Baldwin):
[lld][RISCV] Use an e_flags of 0 if there are only binary input files.
Summary: If none of the input files are ELF object files (for example, when generating an object file from a single binary input file via "-b binary"), use a fallback value for the ELF header flags instead of crashing with an assertion failure.
Reviewers: MaskRay, ruiu, espindola
Reviewed By: MaskRay, ruiu
Subscribers: kevans, grimar, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71101
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356701:
Merge commit f46ba4f07 from llvm git (by Simon Atanasyan):
[mips] Use less registers to load address of TargetExternalSymbol
There is no pattern matched `add hi, (MipsLo texternalsym)`. As a result, loading an address of 32-bit symbol requires two registers and one more additional instruction: ``` addiu $1, $zero, %lo(foo) lui $2, %hi(foo) addu $25, $2, $1 ```
This patch adds the missed pattern and enables generation more effective set of instructions: ``` lui $1, %hi(foo) addiu $25, $1, %lo(foo) ```
Differential Revision: https://reviews.llvm.org/D66771
llvm-svn: 370196
Merge commit 59bb3609f from llvm git (by Simon Atanasyan):
[mips] Fix 64-bit address loading in case of applying 32-bit mask to the result
If result of 64-bit address loading combines with 32-bit mask, LLVM tries to optimize the code and remove "redundant" loading of upper 32-bits of the address. It leads to incorrect code on MIPS64 targets.
MIPS backend creates the following chain of commands to load 64-bit address in the `MipsTargetLowering::getAddrNonPICSym64` method: ``` (add (shl (add (shl (add %highest(sym), %higher(sym)), 16), %hi(sym)), 16), %lo(%sym)) ```
If the mask presents, LLVM decides to optimize the chain of commands. It really does not make sense to load upper 32-bits because the 0x0fffffff mask anyway clears them. After removing redundant commands we get this chain: ``` (add (shl (%hi(sym), 16), %lo(%sym)) ```
There is no patterns matched `(MipsHi (i64 symbol))`. Due a bug in `SYM_32` predicate definition, backend incorrectly selects a pattern for a 32-bit symbols and uses the `lui` instruction for loading `%hi(sym)`.
As a result we get incorrect set of instructions with unnecessary 16-bit left shifting: ``` lui at,0x0 R_MIPS_HI16 foo dsll at,at,0x10 daddiu at,at,0 R_MIPS_LO16 foo ```
This patch resolves two problems: - Fix `SYM_32/SYM_64` predicates to prevent selection of patterns dedicated to 32-bit symbols in case of using N64 ABI. - Add missed patterns for 64-bit symbols for `%hi/%lo`.
Fix PR42736.
Differential Revision: https://reviews.llvm.org/D66228
llvm-svn: 370268
These two commits fix a miscompilation of the kernel for mips64, and should allow clang to be used as the default compiler for mips64.
Requested by: arichards
MFC r356789 (by arichardson):
Merge commit 894f742acb from llvm git (by me):
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible
When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations.
With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references.
I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true.
Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
Merge commit 8e8ccf47 from llvm git (by me)
[MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols
The R_(MICRO)MIPS_JALR optimization only works when used against functions. Using the relocation against a data symbol (e.g. function pointer) will cause some linkers that don't ignore the hint in this case (e.g. LLD prior to commit 5bab291) to generate a relative branch to the data symbol which crashes at run time. Before this patch, LLVM was erroneously emitting these relocations against local-dynamic TLS function pointers and global function pointers with internal visibility.
Reviewers: atanasyan, jrtc27, vstefanovic Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72571
These two changes should allow using lld for MIPS64 (and maybe also MIPS32) by default. The second commit is not strictly necessary for clang+lld since LLD9 will not perform the R_MIPS_JALR optimization (it was only added for 10) but it is probably required in order to use recent ld.bfd.
Reviewed By: dim, emaste Differential Revision: https://reviews.freebsd.org/D23203
MFC r356929:
Merge commit bc4bc5aa0 from llvm git (by Justin Hibbits):
Add 8548 CPU definition and attributes
8548 CPU is GCC's name for the e500v2, so accept this in clang. The e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as well, as GCC does.
Differential Revision: https://reviews.llvm.org/D67787
Merge commit ff0311c4b from llvm git (by Justin Hibbits):
[PowerPC]: Add powerpcspe target triple subarch component
Summary: This allows the use of '-target powerpcspe-unknown-linux-gnu' or 'powerpcspe-unknown-freebsd' to be used, instead of '-target powerpc-unknown-linux-gnu -mspe'.
Reviewed By: dim Differential Revision: https://reviews.llvm.org/D72014
Merge commit ba91dffaf from llvm git (by Fangrui Song):
[Driver][PowerPC] Move powerpcspe logic from cc1 to Driver
Follow-up of D72014. It is more appropriate to use a target feature instead of a SubTypeArch to express the difference.
Reviewed By: #powerpc, jhibbits
Differential Revision: https://reviews.llvm.org/D72433
commit 36eedfcb3 from llvm git (by Justin Hibbits):
[PowerPC] Fix powerpcspe subtarget enablement in llvm backend
Summary:
As currently written, -target powerpcspe will enable SPE regardless of disabling the feature later on in the command line. Instead, change this to just set a default CPU to 'e500' instead of a generic CPU.
As part of this, add FeatureSPE to the e500 definition.
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D72673
These are needed to unbreak the build for powerpcspe.
Requested by: jhibbits
MFC r358711:
Merge commit f75939599 from llvm git (by Erich Keane):
Reland r374450 with Richard Smith's comments and test fixed.
The behavior from the original patch has changed, since we're no longer allowing LLVM to just ignore the alignment. Instead, we're just assuming the maximum possible alignment.
Differential Revision: https://reviews.llvm.org/D68824
llvm-svn: 374562
This fixes 'Assertion failed: (Alignment != 0 && "Invalid Alignment"), function CreateAlignmentAssumption', when building recent versions of v8, which invoke __builtin_assume_aligned() with its alignment argument set to 4GiB or more.
Clang will now report a warning, and show the maximum possible alignment instead, e.g.:
huge-align.cpp:1:27: warning: requested alignment must be 536870912 bytes or smaller; maximum alignment assumed [-Wbuiltin-assume-aligned-alignment] void *f(void *g) { return __builtin_assume_aligned(g, 4294967296); } ^ ~~~~~~~~~~
Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=43839 Reported by: cem |
360660 |
05-May-2020 |
dim |
MFC r355940:
Move all sources from the llvm project into contrib/llvm-project.
This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together.
Updating the vendor area to match this layout is next. |
355940 |
20-Dec-2019 |
dim |
Move all sources from the llvm project into contrib/llvm-project.
This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together.
Updating the vendor area to match this layout is next.
|
355397 |
04-Dec-2019 |
dim |
Merge commit 241cbf201 from llvm git (by Nemanja Ivanovic):
[PowerPC] Fix crash in peephole optimization
When converting reg+reg shifts to reg+imm rotates, we neglect to consider the CodeGenOnly versions of the 32-bit shift mnemonics. This means we produce a rotate with missing operands which causes a crash.
Committing this fix without review since it is non-controversial that the list of mnemonics to consider should include the 64-bit aliases for the exact mnemonics.
Fixes PR44183.
This should fix "Assertion failed: (idx < size()), function operator[], file /usr/src/contrib/llvm/include/llvm/ADT/SmallVector.h, line 153" when building the graphics/mesa-dri port for the PowerPC64 ELFv2 ABI.
Reported by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br> MFC after: 1 month X-MFC-With: r353358
|
354981 |
21-Nov-2019 |
dim |
Merge commit bf996f761 from llvm git (by Simon Atanasyan):
[mips] Write `AFL_EXT_OCTEONP` flag to the `.MIPS.abiflags` section
Differential Revision: https://reviews.llvm.org/D69851
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans MFC after: 1 month X-MFC-With: r353358
|
354980 |
21-Nov-2019 |
dim |
Merge commit 3718102d4 from llvm git (by Simon Atanasyan):
[mips] Support `octeon+` CPU in the `.set arch=` directive
Differential Revision: https://reviews.llvm.org/D69850
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans MFC after: 1 month X-MFC-With: r353358
|
354979 |
21-Nov-2019 |
dim |
Merge commit 7bed381ea from llvm git (by Simon Atanasyan):
[mips] Implement Octeon+ `saa` and `saad` instructions
`saa` and `saad` are 32-bit and 64-bit store atomic add instructions.
memory[base] = memory[base] + rt
These instructions are available for "Octeon+" CPU. The patch adds support for both instructions to MIPS assembler and diassembler and introduces new CPU type - "octeon+".
Next patches will implement `.set arch=octeon+` directive and `AFL_EXT_OCTEONP` ISA extension flag support.
Differential Revision: https://reviews.llvm.org/D69849
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans MFC after: 1 month X-MFC-With: r353358
|
354724 |
15-Nov-2019 |
dim |
Merge commit 5bbb604bb from llvm git (by Craig Topper):
[InstCombine] Disable some portions of foldGEPICmp for GEPs that return a vector of pointers. Fix other portions.
llvm-svn: 370114
This should fix instances of 'Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /usr/src/contrib/llvm/include/llvm/Support/Casting.h, line 255', when building openjdk8 for aarch64 and armv7.
Reported by: jbeich PR: 236566 MFC after: 3 days
|
354707 |
14-Nov-2019 |
emaste |
llvm: use elf_aux_info to get executable's path, if available
Obtained from: LLVM a0a38b81ea MFC with: r354692 Sponsored by: The FreeBSD Foundation
|
354692 |
13-Nov-2019 |
emaste |
llvm: use AT_EXECPATH from ELF auxiliary vectors for getExecutablePath
/proc/curproc/file and the KERN_PROC_PATHNAME sysctl may not return the desired path if there are multiple hardlinks to the file.
PR: 241932 Tested by: ler Sponsored by: The FreeBSD Foundation
|
354469 |
07-Nov-2019 |
dim |
Merge commit f596f4507 from llvm git (by Sam Elliott):
[RISCV] Add Custom Parser for Atomic Memory Operands
Summary: GCC Accepts both (reg) and 0(reg) for atomic instruction memory operands. These instructions do not allow for an offset in their encoding, so in the latter case, the 0 is silently dropped.
Due to how we have structured the RISCVAsmParser, the easiest way to add support for parsing this offset is to add a custom AsmOperand and parser. This parser drops all the parens, and just keeps the register.
This commit also adds a custom printer for these operands, which matches the GCC canonical printer, printing both `(a0)` and `0(a0)` as `(a0)`.
Reviewers: asb, lewis-revill
Reviewed By: asb
Subscribers: s.egerton, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65205
llvm-svn: 367553
Merge commit f596f4507 from llvm git (by Sam Elliott):
[RISCV] Add FreeBSD targets
Reviewers: asb
Reviewed By: asb
Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne, emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57795
Patch by James Clarke (jrtc27)
llvm-svn: 367557
Merge commit f596f4507 from llvm git (by Hsiangkai Wang):
[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.
It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation.
There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types.
Differential Revision: https://reviews.llvm.org/D58335
llvm-svn: 366524
Merge commit f596f4507 from llvm git (by Hsiangkai Wang):
[DebugInfo] Some fields do not need relocations even relax is enabled.
In debug frame information, some fields, e.g., Length in CIE/FDE and Offset in FDE are attributes to describe the structure of CIE/FDE. They are not related to the relaxed code. However, these attributes are symbol differences. So, in current design, these attributes will be filled as zero and LLVM generates relocations for them.
We only need to generate relocations for symbols in executable sections. So, if the symbols are not located in executable sections, we still evaluate their values under relaxation.
Differential Revision: https://reviews.llvm.org/D61584
llvm-svn: 366531
Merge commit f596f4507 from llvm git (by Alex Bradbury):
[RISCV] Don't force absolute FK_Data_X fixups to relocs
The current behavior of shouldForceRelocation forces relocations for the majority of fixups when relaxation is enabled. This makes sense for fixups which incorporate symbols but is unnecessary for simple data fixups where the fixup target is already resolved to an absolute value.
Differential Revision: https://reviews.llvm.org/D63404 Patch by Edward Jones.
llvm-svn: 369257
Merge commit f596f4507 from llvm git (by Alex Bradbury):
[RISCV] Implement getExprForFDESymbol to ensure RISCV_32_PCREL is used for the FDE location
Follow binutils in using RISCV_32_PCREL for the FDE initial location. As explained in the relevant binutils commit <https://github.com/riscv/riscv-binutils-gdb/commit/a6cbf936e3dce68114d28cdf60d510a3f78a6d40>, the ADD/SUB pair of relocations is problematic in the presence of linker relaxation.
This patch has the same end goal as D64715 but includes test changes and avoids adding a new global VariantKind to MCExpr.h (preferring RISCVMCExpr VKs like the rest of the RISC-V backend).
Differential Revision: https://reviews.llvm.org/D66419
llvm-svn: 369375
This series of merges will permit riscv64 kernels and riscv64sf worlds to build with clang instead of gcc (but still using the bfd linker).
Requested by: jhb Obtained from: https://github.com/freebsd/freebsd/compare/master...bsdjhb:riscv_clang MFC after: 1 month X-MFC-With: r353358
|
354429 |
07-Nov-2019 |
dim |
Merge commit 8e34dd941 from llvm git (by Sanjay Patel):
[x86] avoid crashing when splitting AVX stores with non-simple type (PR43916)
The store splitting transform was assuming a simple type (MVT), but that's not necessarily the case as shown in the test.
This should fix 'Assertion failed: (isSimple() && "Expected a SimpleValueType!")' when building the security/openssl111 port targeting a CPU that supports AVX, but not AVX2, such as sandybridge.
PR: 241747 MFC after: 1 month X-MFC-With: r353358
|
354339 |
04-Nov-2019 |
dim |
Merge commit 97e362607 from llvm git (by Nemanja Ivanovic):
[PowerPC] Do not emit HW loop if the body contains calls to lrint/lround
These two intrinsics are lowered to calls so should prevent the formation of CTR loops. In a subsequent patch, we will handle all currently known intrinsics and prevent the formation of HW loops if any unknown intrinsics are encountered.
Differential revision: https://reviews.llvm.org/D68841
This should fix an "invalid CRT loop" assertion when building the www/node port for powerpc64.
Requested by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br> MFC after: 1 month X-MFC-With: r353358
|
354146 |
29-Oct-2019 |
dim |
Pull in r373338 from upstream llvm trunk (by Simon Pilgrim):
Revert rL349624 : Let TableGen write output only if it changed, instead of doing so in cmake, attempt 2
Differential Revision: https://reviews.llvm.org/D55842 ----------------- As discussed on PR43385 this is causing Visual Studio msbuilds to perpetually rebuild all tablegen generated files
Pull in r373664 from upstream llvm trunk (by Nico Weber):
Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake
Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385.
This should fix the scenario where an incremental build from before r353358 (the clang 9.0.0 upgrade) to r353358 or later fails to update the timestamp of the generated lib/clang/headers/arm_fp16.h header.
After such a build, installing world from read-only source and object directories would attempt to generate the header again, leading to "clang-tblgen: error opening arm_fp16.h.d:Read-only file system".
Reported by: avg, np PR: 241402 MFC after: 1 month X-MFC-With: r353358
|
354097 |
25-Oct-2019 |
dim |
Pull in r372186 from upstream llvm trunk (by Eli Friedman):
[ARM] VFPv2 only supports 16 D registers.
r361845 changed the way we handle "D16" vs. "D32" targets; there used to be a negative "d16" which removed instructions from the instruction set, and now there's a "d32" feature which adds instructions to the instruction set. This is good, but there was an oversight in the implementation: the behavior of VFPv2 was changed. In particular, the "vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only supports 16 D registers.
In practice, this means if you specify -mfpu=vfpv2, the compiler will generate illegal instructions.
This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and "vfp2sp" so they don't imply "d32".
Differential Revision: https://reviews.llvm.org/D67375
Pull in r372187 from upstream clang trunk (by Eli Friedman):
[ARM] Update clang for removal of vfp2d16 and vfp2d16sp
Matching fix for https://reviews.llvm.org/D67375 (r372186).
Differential Revision: https://reviews.llvm.org/D67467
This should fix clang generating invalid opcodes for floating point operations on armv6.
Requested by: mmel MFC after: 3 days
|
353358 |
09-Oct-2019 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316.
Release notes for llvm, clang, lld and libc++ 9.0.0 are available here:
https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html
PR: 240629 MFC after: 1 month
|
352915 |
30-Sep-2019 |
dim |
Pull in r357528 from upstream llvm trunk (by Craig Topper):
[X86] Check MI.isConvertibleTo3Addr() before calling convertToThreeAddress in X86FixupLEAs.
X86FixupLEAs just assumes convertToThreeAddress will return nullptr for any instruction that isn't convertible.
But the code in convertToThreeAddress for X86 assumes that any instruction coming in has at least 2 operands and that the second one is a register. But those properties aren't guaranteed of all instructions. We should check the instruction property first.
Pull in r365720 from upstream llvm trunk (by Craig Topper):
[X86] Don't convert 8 or 16 bit ADDs to LEAs on Atom in FixupLEAPass.
We use the functions that convert to three address to do the conversion, but changing an 8 or 16 bit will cause it to create a virtual register. This can't be done after register allocation where this pass runs.
I've switched the pass completely to a white list of instructions that can be converted to LEA instead of a blacklist that was incorrect. This will avoid surprises if we enhance the three address conversion function to include additional instructions in the future.
Fixes PR42565.
This should fix assertions/segfaults when compiling certain ports with CPUTYPE=atom.
PR: 240928 MFC after: 3 days
|
352171 |
10-Sep-2019 |
imp |
Remove dirs (and their now-empty parents) empty since r344779
|
352168 |
10-Sep-2019 |
imp |
Remove dirs empty since r280031
|
351938 |
06-Sep-2019 |
dim |
Pull in r371111 from upstream llvm trunk (by Eli Friedman):
[IfConversion] Fix diamond conversion with unanalyzable branches.
The code was incorrectly counting the number of identical instructions, and therefore tried to predicate an instruction which should not have been predicated. This could have various effects: a compiler crash, an assembler failure, a miscompile, or just generating an extra, unnecessary instruction.
Instead of depending on TargetInstrInfo::removeBranch, which only works on analyzable branches, just remove all branch instructions.
Fixes https://bugs.llvm.org/show_bug.cgi?id=43121 and https://bugs.llvm.org/show_bug.cgi?id=41121 .
Differential Revision: https://reviews.llvm.org/D67203
This should fix "Unable to predicate BX killed renamable $r0" errors when building the lang/spidermonkey170 and lang/spidermonkey38 ports for armv7 and armv6.
PR: 236567 MFC after: 3 days
|
350362 |
26-Jul-2019 |
dim |
Pull in r366369 from upstream llvm trunk (by Francis Visoiu Mistrih):
[CodeGen][NFC] Simplify checks for stack protector index checking
Use `hasStackProtectorIndex()` instead of `getStackProtectorIndex() >= 0`.
Pull in r366371 from upstream llvm trunk (by Francis Visoiu Mistrih):
[PEI] Don't re-allocate a pre-allocated stack protector slot
The LocalStackSlotPass pre-allocates a stack protector and makes sure that it comes before the local variables on the stack.
We need to make sure that later during PEI we don't re-allocate a new stack protector slot. If that happens, the new stack protector slot will end up being **after** the local variables that it should be protecting.
Therefore, we would have two slots assigned for two different stack protectors, one at the top of the stack, and one at the bottom. Since PEI will overwrite the assigned slot for the stack protector, the load that is used to compare the value of the stack protector will use the slot assigned by PEI, which is wrong.
For this, we need to check if the object is pre-allocated, and re-use that pre-allocated slot.
Differential Revision: https://reviews.llvm.org/D64757
Pull in r367068 from upstream llvm trunk (by Francis Visoiu Mistrih):
[CodeGen] Don't resolve the stack protector frame accesses until PEI
Currently, stack protector loads and stores are resolved during LocalStackSlotAllocation (if the pass needs to run). When this is the case, the base register assigned to the frame access is going to be one of the vregs created during LocalStackSlotAllocation. This means that we are keeping a pointer to the stack protector slot, and we're using this pointer to load and store to it.
In case register pressure goes up, we may end up spilling this pointer to the stack, which can be a security concern.
Instead, leave it to PEI to resolve the frame accesses. In order to do that, we make all stack protector accesses go through frame index operands, then PEI will resolve this using an offset from sp/fp/bp.
Differential Revision: https://reviews.llvm.org/D64759
Together, these fix a issue where the stack protection feature in LLVM's ARM backend can be rendered ineffective when the stack protector slot is re-allocated so that it appears after the local variables that it is meant to protect, leaving the function potentially vulnerable to a stack-based buffer overflow.
Reported by: andrew Security: https://kb.cert.org/vuls/id/129209/ MFC after: 3 days
|
349583 |
01-Jul-2019 |
dim |
Pull in r360968 from upstream llvm trunk (by Philip Reames):
Clarify comments on helpers used by LFTR [NFC]
I'm slowly wrapping my head around this code, and am making comment improvements where I can.
Pull in r360972 from upstream llvm trunk (by Philip Reames):
[LFTR] Factor out a helper function for readability purpose [NFC]
Pull in r360976 from upstream llvm trunk (by Philip Reames):
[IndVars] Don't reimplement Loop::isLoopInvariant [NFC]
Using dominance vs a set membership check is indistinguishable from a compile time perspective, and the two queries return equivelent results. Simplify code by using the existing function.
Pull in r360978 from upstream llvm trunk (by Philip Reames):
[LFTR] Strengthen assertions in genLoopLimit [NFCI]
Pull in r362292 from upstream llvm trunk (by Nikita Popov):
[IndVarSimplify] Fixup nowrap flags during LFTR (PR31181)
Fix for https://bugs.llvm.org/show_bug.cgi?id=31181 and partial fix for LFTR poison handling issues in general.
When LFTR moves a condition from pre-inc to post-inc, it may now depend on value that is poison due to nowrap flags. To avoid this, we clear any nowrap flag that SCEV cannot prove for the post-inc addrec.
Additionally, LFTR may switch to a different IV that is dynamically dead and as such may be arbitrarily poison. This patch will correct nowrap flags in some but not all cases where this happens. This is related to the adoption of IR nowrap flags for the pre-inc addrec. (See some of the switch_to_different_iv tests, where flags are not dropped or insufficiently dropped.)
Finally, there are likely similar issues with the handling of GEP inbounds, but we don't have a test case for this yet.
Differential Revision: https://reviews.llvm.org/D60935
Pull in r362971 from upstream llvm trunk (by Philip Reames):
Prepare for multi-exit LFTR [NFC]
This change does the plumbing to wire an ExitingBB parameter through the LFTR implementation, and reorganizes the code to work in terms of a set of individual loop exits. Most of it is fairly obvious, but there's one key complexity which makes it worthy of consideration. The actual multi-exit LFTR patch is in D62625 for context.
Specifically, it turns out the existing code uses the backedge taken count from before a IV is widened. Oddly, we can end up with a different (more expensive, but semantically equivelent) BE count for the loop when requerying after widening. For the nestedIV example from elim-extend, we end up with the following BE counts: BEFORE: (-2 + (-1 * %innercount) + %limit) AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>)
This is the only test in tree which seems sensitive to this difference. The actual result of using the wider BETC on this example is that we actually produce slightly better code. :)
In review, we decided to accept that test change. This patch is structured to preserve the old behavior, but a separate change will immediate follow with the behavior change. (I wanted it separate for problem attribution purposes.)
Differential Revision: https://reviews.llvm.org/D62880
Pull in r362975 from upstream llvm trunk (by Philip Reames):
[LFTR] Use recomputed BE count
This was discussed as part of D62880. The basic thought is that computing BE taken count after widening should produce (on average) an equally good backedge taken count as the one before widening. Since there's only one test in the suite which is impacted by this change, and it's essentially equivelent codegen, that seems to be a reasonable assertion. This change was separated from r362971 so that if this turns out to be problematic, the triggering piece is obvious and easily revertable.
For the nestedIV example from elim-extend.ll, we end up with the following BE counts: BEFORE: (-2 + (-1 * %innercount) + %limit) AFTER: (-1 + (sext i32 (-1 + %limit) to i64) + (-1 * (sext i32 %innercount to i64))<nsw>)
Note that before is an i32 type, and the after is an i64. Truncating the i64 produces the i32.
Pull in r362980 from upstream llvm trunk (by Philip Reames):
Factor out a helper function for readability and reuse in a future patch [NFC]
Pull in r363613 from upstream llvm trunk (by Philip Reames):
Fix a bug w/inbounds invalidation in LFTR (recommit)
Recommit r363289 with a bug fix for crash identified in pr42279. Issue was that a loop exit test does not have to be an icmp, leading to a null dereference crash when new logic was exercised for that case. Test case previously committed in r363601.
Original commit comment follows:
This contains fixes for two cases where we might invalidate inbounds and leave it stale in the IR (a miscompile). Case 1 is when switching to an IV with no dynamically live uses, and case 2 is when doing pre-to-post conversion on the same pointer type IV.
The basic scheme used is to prove that using the given IV (pre or post increment forms) would have to already trigger UB on the path to the test we're modifying. As such, our potential UB triggering use does not change the semantics of the original program.
As was pointed out in the review thread by Nikita, this is defending against a separate issue from the hasConcreteDef case. This is about poison, that's about undef. Unfortunately, the two are different, see Nikita's comment for a fuller explanation, he explains it well.
(Note: I'm going to address Nikita's last style comment in a separate commit just to minimize chance of subtle bugs being introduced due to typos.)
Differential Revision: https://reviews.llvm.org/D62939
Pull in r363875 from upstream llvm trunk (by Philip Reames):
[LFTR] Rename variable to minimize confusion [NFC]
(Recommit of r363293 which was reverted when a dependent patch was.)
As pointed out by Nikita in D62625, BackedgeTakenCount is generally used to refer to the backedge taken count of the loop. A conditional backedge taken count - one which only applies if a particular exit is taken - is called a ExitCount in SCEV code, so be consistent here.
Pull in r363877 from upstream llvm trunk (by Philip Reames):
[LFTR] Stylistic cleanup as suggested in last review comment of D62939 [NFC]
(Resumbit of r363292 which was reverted along w/an earlier patch)
Pull in r364346 from upstream llvm trunk (by Philip Reames):
[LFTR] Adjust debug output to include extensions (if any)
Pull in r364693 from upstream llvm trunk (by Philip Reames):
[IndVars] Remove a bit of manual constant folding [NFC]
SCEV is more than capable of folding (add x, trunc(0)) to x.
Pull in r364709 from upstream llvm trunk (by Nikita Popov):
[LFTR] Fix post-inc pointer IV with truncated exit count (PR41998)
Fixes https://bugs.llvm.org/show_bug.cgi?id=41998. Usually when we have a truncated exit count we'll truncate the IV when comparing against the limit, in which case exit count overflow in post-inc form doesn't matter. However, for pointer IVs we don't do that, so we have to be careful about incrementing the IV in the wide type.
I'm fixing this by removing the IVCount variable (which was ExitCount or ExitCount+1) and replacing it with a UsePostInc flag, and then moving the actual limit adjustment to the individual cases (which are: pointer IV where we add to the wide type, integer IV where we add to the narrow type, and constant integer IV where we add to the wide type).
Differential Revision: https://reviews.llvm.org/D63686
Together, these should fix a hang when building the textproc/htmldoc port, due to an incorrect loop optimization.
PR: 237515 MFC after: 1 week
|
349351 |
25-Jun-2019 |
jhibbits |
powerpc: Transition to Secure-PLT, like most other OSs (Toolchain part)
Summary: Toolchain follow-up to r349350. LLVM patches will be submitted upstream for 9.0 as well.
The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it cannot determine for certain that it needs Secure-PLT, and some binaries do not compile in such a way to make it know to use Secure-PLT.
Reviewed By: nwhitehorn, bdragon, pfg Differential Revision: https://reviews.freebsd.org/D20598
|
349004 |
12-Jun-2019 |
dim |
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
|
348288 |
26-May-2019 |
dim |
Pull in r361696 from upstream llvm trunk (by Sanjay Patel):
[SelectionDAG] soften assertion when legalizing narrow vector FP ops
The test based on PR42010: https://bugs.llvm.org/show_bug.cgi?id=42010
...may show an inaccuracy for PPC's target defs, but we should not be so aggressive with an assert here. There's no telling what out-of-tree targets look like.
This fixes an assertion when building the graphics/mesa-dri port for PowerPC64.
Reported by: Mark Millard <marklmi26-fbsd@yahoo.com> PR: 238082 MFC after: 3 days
|
347243 |
08-May-2019 |
dim |
Pull in r360099 from upstream llvm trunk (by Eli Friedman):
[ARM] Glue register copies to tail calls.
This generally follows what other targets do. I don't completely understand why the special case for tail calls existed in the first place; even when the code was committed in r105413, call lowering didn't work in the way described in the comments.
Stack protector lowering breaks if the register copies are not glued to a tail call: we have to insert the stack protector check before the tail call, and we choose the location based on the assumption that all physical register dependencies of a tail call are adjacent to the tail call. (See FindSplitPointForStackProtector.) This is sort of fragile, but I don't see any reason to break that assumption.
I'm guessing nobody has seen this before just because it's hard to convince the scheduler to actually schedule the code in a way that breaks; even without the glue, the only computation that could actually be scheduled after the register copies is the computation of the call address, and the scheduler usually prefers to schedule that before the copies anyway.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41417
Differential Revision: https://reviews.llvm.org/D60427
This should fix several instances of "Bad machine code: Using an undefined physical register", when compiling ports such as multimedia/vlc, audio/alsa-lib and devel/avro-c for armv6, with -fstack-protector-strong.
Reported by: jbeich PR: 237074, 237783, 237784 MFC after: 3 days
|
345449 |
23-Mar-2019 |
dim |
Pull in r356809 from upstream llvm trunk (by Eli Friedman):
[ARM] Don't form "ands" when it isn't scheduled correctly.
In r322972/r323136, the iteration here was changed to catch cases at the beginning of a basic block... but we accidentally deleted an important safety check. Restore that check to the way it was.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41116
Differential Revision: https://reviews.llvm.org/D59680
This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe port for armv7.
PR: 236062, 236568 MFC after: 1 month X-MFC-With: r344779
|
345073 |
12-Mar-2019 |
dim |
Revert r308867 (which was originally committed in the clang390-import project branch):
Work around LLVM PR30879, which is about a bad interaction between X86 Call Frame Optimization on i386 and libunwind, by disallowing the optimization for i386-freebsd12.
This should fix some instances of broken exception handling when frame pointers are omitted, in particular some unittests run during the build of editors/libreoffice.
This hack will be removed as soon as upstream has implemented a more permanent fix for this problem.
And indeed, after r345018 and r345019, which updated LLVM libunwind to the most recent version, the above workaround is no longer needed. The upstream commit which fixed this is:
https://llvm.org/viewvc/llvm-project?view=revision&revision=292723
Specifically, 32 bit (i386-freebsd) executables optimized with omitted frame pointers and Call Frame Optimization should now behave correctly when a C++ exception is thrown, and the stack is unwound.
Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879 PR: 236062 MFC after: 1 month X-MFC-With: r344779
|
345021 |
11-Mar-2019 |
dim |
Pull in r355854 from upstream llvm trunk (by Jonas Paulsson):
[RegAlloc] Avoid compile time regression with multiple copy hints.
As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive compile time building opencollada"), this patch makes sure that no phys reg is hinted more than once from getRegAllocationHints().
This handles the case were many virtual registers are assigned to the same physreg. The previous compile time fix (r343686) in weightCalcHelper() only made sure that physical/virtual registers are passed no more than once to addRegAllocationHint().
Review: Dimitry Andric, Quentin Colombet https://reviews.llvm.org/D59201
This should fix a hang when compiling certain generated .cpp files in the graphics/opencollada port.
PR: 236313 MFC after: 1 month X-MFC-With: r344779
|
344779 |
04-Mar-2019 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected.
Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html>
PR: 236062 Relnotes: yes MFC after: 1 month
|
344503 |
24-Feb-2019 |
dim |
Pull in r354756 from upstream llvm trunk (by Craig Topper):
[X86] Fix tls variable lowering issue with large code model
Summary: The problem here is the lowering for tls variable. Below is the DAG for the code. SelectionDAG has 11 nodes:
t0: ch = EntryToken t8: i64,ch = load<(load 8 from `i8 addrspace(257)* null`, addrspace 257)> t0, Constant:i64<0>, undef:i64 t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=10] t11: i64,ch = load<(load 8 from got)> t0, t10, undef:i64 t12: i64 = add t8, t11 t4: i32,ch = load<(dereferenceable load 4 from @x)> t0, t12, undef:i64 t6: ch = CopyToReg t0, Register:i32 %0, t4
And when mcmodel is large, below instruction can NOT be folded.
t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=10] t11: i64,ch = load<(load 8 from got)> t0, t10, undef:i64
So "t11: i64,ch = load<(load 8 from got)> t0, t10, undef:i64" is lowered to " Morphed node: t11: i64,ch = MOV64rm<Mem:(load 8 from got)> t10, TargetConstant:i8<1>, Register:i64 $noreg, TargetConstant:i32<0>, Register:i32 $noreg, t0"
When llvm start to lower "t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=10]", it fails.
The patch is to fold the load and X86ISD::WrapperRIP.
Fixes PR26906
Patch by LuoYuanke
Reviewers: craig.topper, rnk, annita.zhang, wxiao3
Reviewed By: rnk
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58336
This should fix "fatal error: error in backend: Cannot select" messages when compiling <ctype.h> functions using -mcmodel=large.
Reported by: phk PR: 233143 MFC after: 3 days
|
344112 |
13-Feb-2019 |
dim |
Pull in r353907 from upstream llvm trunk (by Reid Kleckner):
[MC] Make symbol version errors non-fatal
We stil don't have a source location, which is pretty lame, but at least we won't tell the user to file a clang bug report anymore.
Fixes PR40712
This will make errors for symbols with @@ versions that are not defined non-fatal. For example:
void f(void) { __asm__(".symver foo,bar@@baz"); }
will now result in:
error: versioned symbol bar@@baz must be defined
instead of clang crashing with a diagnostic report.
PR: 234671 Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40712 MFC after: 3 days
|
344056 |
12-Feb-2019 |
dim |
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.
|
343916 |
08-Feb-2019 |
dim |
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
|
342593 |
29-Dec-2018 |
dim |
Pull in r342863 from upstream llvm trunk (by Hans Wennborg):
Remove debug printf leftover from r342397
PR: 234480 MFC after: 6 weeks X-MFC-With: r341825
|
342592 |
29-Dec-2018 |
dim |
Pull in r342397 from upstream llvm trunk (by Amara Emerson):
Revert "Revert r342183 "[DAGCombine] Fix crash when store merging created an extract_subvector with invalid index.""
Fixed the assertion failure.
Differential Revision: https://reviews.llvm.org/D51831
This fixes 'Assertion failed: ((VT.getVectorNumElements() + N2C->getZExtValue() <= N1.getValueType().getVectorNumElements()) && "Extract subvector overflow!"), function getNode' when building the multimedia/aom port (with AVX2 enabled).
Reported by: jbeich PR: 234480 MFC after: 6 weeks X-MFC-With: r341825
|
341825 |
11-Dec-2018 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The release will follow very soon, but no more functional changes are expected.
Release notes for llvm, clang and lld 7.0.0 are available here: <http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html>
PR: 230240, 230355 Relnotes: yes MFC after: 2 months
|
338689 |
14-Sep-2018 |
dim |
Pull in r335365 from upstream llvm trunk (by Krzysztof Parzyszek):
Initialize LiveRegs once in BranchFolder::mergeCommonTails
This should fix '(TRI && "LivePhysRegs is not initialized."' assertions when building the lang/qt5-qml port in certain configurations.
Approved by: re (kib) Reported by: Piotr Kubaj <pkubaj@anongoth.pl> PR: 231355 MFC after: 3 days
|
337615 |
11-Aug-2018 |
dim |
Pull in r338481 from upstream llvm trunk (by Chandler Carruth):
[x86] Fix a really subtle miscompile due to a somewhat glaring bug in EFLAGS copy lowering.
If you have a branch of LLVM, you may want to cherrypick this. It is extremely unlikely to hit this case empirically, but it will likely manifest as an "impossible" branch being taken somewhere, and will be ... very hard to debug.
Hitting this requires complex conditions living across complex control flow combined with some interesting memory (non-stack) initialized with the results of a comparison. Also, because you have to arrange for an EFLAGS copy to be in *just* the right place, almost anything you do to the code will hide the bug. I was unable to reduce anything remotely resembling a "good" test case from the place where I hit it, and so instead I have constructed synthetic MIR testing that directly exercises the bug in question (as well as the good behavior for completeness).
The issue is that we would mistakenly assume any SETcc with a valid condition and an initial operand that was a register and a virtual register at that to be a register *defining* SETcc...
It isn't though....
This would in turn cause us to test some other bizarre register, typically the base pointer of some memory. Now, testing this register and using that to branch on doesn't make any sense. It even fails the machine verifier (if you are running it) due to the wrong register class. But it will make it through LLVM, assemble, and it *looks* fine... But wow do you get a very unsual and surprising branch taken in your actual code.
The fix is to actually check what kind of SETcc instruction we're dealing with. Because there are a bunch of them, I just test the may-store bit in the instruction. I've also added an assert for sanity that ensure we are, in fact, *defining* the register operand. =D
Noticed by: kib MFC after: 1 week
|
335799 |
29-Jun-2018 |
dim |
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
|
333715 |
17-May-2018 |
dim |
Pull in r322325 from upstream llvm trunk (by Matthias Braun):
PeepholeOpt cleanup/refactor; NFC
- Less unnecessary use of `auto` - Add early `using RegSubRegPair(AndIdx) =` to avoid countless `TargetInstrInfo::` qualifications. - Use references instead of pointers where possible. - Remove unused parameters. - Rewrite the CopyRewriter class hierarchy: - Pull out uncoalescable copy rewriting functionality into PeepholeOptimizer class. - Use an abstract base class to make it clear that rewriters are independent. - Remove unnecessary \brief in doxygen comments. - Remove unused constructor and method from ValueTracker. - Replace UseAdvancedTracking of ValueTracker with DisableAdvCopyOpt use.
Even though upstream marked this as "No Functional Change", it does contain some functional changes, and these fix a compiler hang for one particular source file in the devel/godot port.
PR: 228261 MFC after: 3 days
|
332898 |
23-Apr-2018 |
dim |
Pull in r329771 from upstream llvm trunk (by Craig Topper):
[X86] In X86FlagsCopyLowering, when rewriting a memory setcc we need to emit an explicit MOV8mr instruction.
Previously the code only knew how to handle setcc to a register.
This should fix a crash in the chromium build.
This fixes various assertion failures while building ports targeting i386: * www/firefox: isReg() && "This is not a register operand!" * www/iridium, www/qt5-webengine: (I.atEnd() || std::next(I) == def_instr_end()) && "getVRegDef assumes a single definition or no definition" * devel/powerpc64-gcc: FromReg != ToReg && "Cannot replace a reg with itself"
Reported by: jbeich PR: 225330, 227686, 227698, 227699 MFC after: 1 week X-MFC-With: r332833
|
332833 |
20-Apr-2018 |
dim |
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
|
332503 |
14-Apr-2018 |
dim |
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
|
332501 |
14-Apr-2018 |
dim |
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
|
331366 |
22-Mar-2018 |
dim |
Pull in r327101 from upstream llvm trunk (by Rafael Espindola):
Don't treat .symver as a regular alias definition.
This patch starts simplifying the handling of .symver.
For now it just moves the responsibility for creating an alias down to the streamer. With that the asm streamer can pass a .symver unchanged, which is nice since gas cannot parse "foo@bar = zed".
In a followup I hope to move the handling down to the writer so that we don't need special hacks for avoiding breaking names with @@@ on windows.
Pull in r327160 from upstream llvm trunk (by Rafael Espindola):
Delay creating an alias for @@@.
With this we only create an alias for @@@ once we know if it should use @ or @@. This avoids last minutes renames and hacks to handle MS names.
This only handles the ELF writer. LTO still has issues with @@@ aliases.
Pull in r327928 from upstream llvm trunk (by Vitaly Buka):
Object: Move attribute calculation into RecordStreamer. NFC
Summary: Preparation for D44274
Reviewers: pcc, espindola
Subscribers: hiraditya
Differential Revision: https://reviews.llvm.org/D44276
Pull in r327930 from upstream llvm trunk (by Vitaly Buka):
Object: Fix handling of @@@ in .symver directive
Summary: name@@@nodename is going to be replaced with name@@nodename if symbols is defined in the assembled file, or name@nodename if undefined. https://sourceware.org/binutils/docs/as/Symver.html
Fixes PR36623
Reviewers: pcc, espindola
Subscribers: mehdi_amini, hiraditya
Differential Revision: https://reviews.llvm.org/D44274
Together, these changes fix handling of @@@ in .symver directives when doing Link Time Optimization.
Reported by: Shawn Webb <shawn.webb@hardenedbsd.org> MFC after: 3 months X-MFC-With: r327952
|
331065 |
16-Mar-2018 |
dim |
Pull in r327638 from upstream llvm trunk (by Matthew Simpson):
[ConstantFolding, InstSimplify] Handle more vector GEPs
This patch addresses some additional cases where the compiler crashes upon encountering vector GEPs. This should fix PR36116.
Differential Revision: https://reviews.llvm.org/D44219 Reference: https://bugs.llvm.org/show_bug.cgi?id=36116
This fixes an assertion when building the emulators/snes9x port.
Reported by: jbeich PR: 225471 MFC after: 3 months X-MFC-With: r327952
|
330686 |
09-Mar-2018 |
dim |
Pull in r326882 from upstream llvm trunk (by Sjoerd Meijer):
[ARM] Fix for PR36577
Don't PerformSHLSimplify if the given node is used by a node that also uses a constant because we may get stuck in an infinite combine loop.
bugzilla: https://bugs.llvm.org/show_bug.cgi?id=36577
Patch by Sam Parker.
Differential Revision: https://reviews.llvm.org/D44097
This fixes a hang when compiling one particular file in java/openjdk8 for armv6 and armv7.
Reported by: swills PR: 226388
|
330384 |
04-Mar-2018 |
dim |
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
|
329983 |
25-Feb-2018 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r325932). This corresponds to 6.0.0 rc3.
MFC after: 3 months X-MFC-With: r327952 PR: 224669
|
329410 |
16-Feb-2018 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r325330).
MFC after: 3 months X-MFC-With: r327952 PR: 224669
|
328817 |
02-Feb-2018 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r324090).
This introduces retpoline support, with the -mretpoline flag. The upstream initial commit message (r323155 by Chandler Carruth) contains quite a bit of explanation. Quoting:
Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre.
Summary: First, we need to explain the core of the vulnerability. Note that this is a very incomplete description, please see the Project Zero blog post for details: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution of the processor to some "gadget" of executable code by poisoning the prediction of indirect branches with the address of that gadget. The gadget in turn contains an operation that provides a side channel for reading data. Most commonly, this will look like a load of secret data followed by a branch on the loaded value and then a load of some predictable cache line. The attacker then uses timing of the processors cache to determine which direction the branch took *in the speculative execution*, and in turn what one bit of the loaded value was. Due to the nature of these timing side channels and the branch predictor on Intel processors, this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We introduce a new construct we call a "retpoline" to implement indirect calls in a non-speculatable way. It can be thought of loosely as a trampoline for indirect calls which uses the RET instruction on x86. Further, we arrange for a specific call->ret sequence which ensures the processor predicts the return to go to a controlled, known location. The retpoline then "smashes" the return address pushed onto the stack by the call with the desired target of the original indirect call. The result is a predicted return to the next instruction after a call (which can be used to trap speculative execution within an infinite loop) and an actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by using a guaranteed scratch register to pass the target into this device. For 32-bit ABIs there isn't a guaranteed scratch register and so several different retpoline variants are introduced to use a scratch register if one is available in the calling convention and to otherwise use direct stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline thunk by the compiler to allow for custom thunks if users want them. These are particularly useful in environments like kernels that routinely do hot-patching on boot and want to hot-patch their thunk to different code sequences. They can write this custom thunk and use `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this case, on x86-64 thu thunk names must be: ``` __llvm_external_retpoline_r11 ``` or on 32-bit: ``` __llvm_external_retpoline_eax __llvm_external_retpoline_ecx __llvm_external_retpoline_edx __llvm_external_retpoline_push ``` And the target of the retpoline is passed in the named register, or in the case of the `push` suffix on the top of the stack via a `pushl` instruction.
There is one other important source of indirect branches in x86 ELF binaries: the PLT. These patches also include support for LLD to generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from precompiled runtimes (such as crt0.o and similar). The ones we have found are not really attackable, and so we have not focused on them here, but eventually these runtimes should also be replicated for retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the compiler switch `-mretpoline` is sufficient to fully mitigate this particular attack. For dynamic executables, you must compile *all* libraries with `-mretpoline` and additionally link the dynamic executable and all shared libraries with LLD and pass `-z retpolineplt` (or use similar functionality from some other linker). We strongly recommend also using `-z now` as non-lazy binding allows the retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the Linux kernel we observed very small performance hits to applications running typic al workloads, and relatively minor hits (approximately 2%) even for extremely syscall-heavy applications. This is largely due to the small number of indirect branches that occur in performance sensitive paths of the kernel.
When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline.
We will add detailed documentation covering these components in subsequent patches, but wanted to make the core functionality available as soon as possible. Happy for more code review, but we'd really like to get these patches landed and backported ASAP for obvious reasons. We're planning to backport this to both 6.0 and 5.0 release streams and get a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid, Rui, and myself. I'm mailing it out as a single commit due to the time sensitive nature of landing this and the need to backport it. Huge thanks to everyone who helped out here, and everyone at Intel who helped out in discussions about how to craft this. Also, credit goes to Paul Turner (at Google, but not an LLVM contributor) for much of the underlying retpoline design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
MFC after: 3 months X-MFC-With: r327952 PR: 224669
|
328753 |
01-Feb-2018 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r323948).
MFC after: 3 months X-MFC-With: r327952 PR: 224669
|
328596 |
30-Jan-2018 |
emaste |
Pull in r322131 from upstream llvm trunk (by Rafael EspÃndola):
Use a MCExpr for the size of MCFillFragment.
This allows the size to be found during ralaxation. This fixes [LLVM] pr35858.
Requested by: royger
|
328595 |
30-Jan-2018 |
emaste |
Pull in r322123 from upstream llvm trunk (by Rafael EspÃndola):
Don't create MCFillFragment directly.
Instead use higher level APIs that take care of most bookkeeping.
|
328594 |
30-Jan-2018 |
emaste |
Pull in r322108 from upstream llvm trunk (by Rafael EspÃndola):
Make one of the emitFill methods non virtual. NFC.
This is just preparatory work to fix [LLVM] PR35858.
|
328381 |
24-Jan-2018 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r323338).
MFC after: 3 months X-MFC-With: r327952 PR: 224669
|
328146 |
18-Jan-2018 |
dim |
Pull in r322106 from upstream llvm trunk (by Alexey Bataev):
[COST]Fix PR35865: Fix cost model evaluation for shuffle on X86.
Summary: If the vector type is transformed to non-vector single type, the compile may crash trying to get vector information about non-vector type.
Reviewers: RKSimon, spatel, mkuper, hfinkel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41862
This should fix "Not a vector MVT!" errors when building the games/dhewm3 port.
Reported by: jbeich PR: 225271
|
328145 |
18-Jan-2018 |
dim |
Pull in r322016 from upstream llvm trunk (by Sanjay Patel):
[ValueTracking] remove overzealous assert
The test is derived from a failing fuzz test: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5008
Credit to @rksimon for pointing out the problem.
This should fix "Bad flavor while matching min/max" errors when building the graphics/libsixel and science/kst2 ports.
Reported by: jbeich PR: 225268, 225269
|
328090 |
17-Jan-2018 |
dim |
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
|
328010 |
15-Jan-2018 |
dim |
Pull in r322473 from upstream llvm trunk (by Andrei Elovikov):
[LV] Don't call recordVectorLoopValueForInductionCast for newly-created IV from a trunc.
Summary: This method is supposed to be called for IVs that have casts in their use-def chains that are completely ignored after vectorization under PSE. However, for truncates of such IVs the same InductionDescriptor is used during creation/widening of both original IV based on PHINode and new IV based on TruncInst.
This leads to unintended second call to recordVectorLoopValueForInductionCast with a VectorLoopVal set to the newly created IV for a trunc and causes an assert due to attempt to store new information for already existing entry in the map. This is wrong and should not be done.
Fixes PR35773.
Reviewers: dorit, Ayal, mssimpso
Reviewed By: dorit
Subscribers: RKSimon, dim, dcaballe, hsaito, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D41913
This should fix "Vector value already set for part" assertions when building the net/iodine and sysutils/daa2iso ports.
Reported by: jbeich PR: 224867,224868
|
327952 |
14-Jan-2018 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r321788). Upstream has branched for the 6.0.0 release, which should be in about 6 weeks. Please report bugs and regressions, so we can get them into the release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
MFC after: 3 months
|
327845 |
11-Jan-2018 |
dim |
Pull in r316581 from upstream llvm trunk (by John Baldwin):
Don't try to use a non-existent header on FreeBSD/mips.
Reviewers: dim
Differential Revision: https://reviews.llvm.org/D38807
Requested by: jhb MFC after: 3 days
|
326909 |
16-Dec-2017 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.1 release (upstream r320880).
Relnotes: yes MFC after: 2 weeks
|
326496 |
03-Dec-2017 |
dim |
Upgrade our copies of clang, llvm, lldb and libc++ to r319231 from the upstream release_50 branch. This corresponds to 5.0.1 rc2.
MFC after: 2 weeks
|
325420 |
05-Nov-2017 |
emaste |
lld: accept EINVAL to indicate posix_fallocate is unsupported
As of r325320 posix_fallocate on a ZFS filesystem returns EINVAL to indicate that the operation is not supported. (I think this is a strange choice of errno on the part of POSIX.)
PR: 223383, 223440 Reported by: Mark Millard Tested by: Mark Millard MFC after: 3 days Sponsored by: The FreeBSD Foundation
|
324826 |
21-Oct-2017 |
dim |
Pull in r316035 from upstream llvm trunk (by Tim Northover):
AArch64: account for possible frame index operand in compares.
If the address of a local is used in a comparison, AArch64 can fold the address-calculation into the comparison via "adds". Unfortunately, a couple of places (both hit in this one test) are not ready to deal with that yet and just assume the first source operand is a register.
This should fix an assertion failure while building the test suite of www/firefox for AArch64.
PR: 223048 MFC after: 3 days
|
323245 |
06-Sep-2017 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.0 release (upstream r312559).
Release notes for llvm, clang and lld will be available here soon: <http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/5.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.html>
Relnotes: yes MFC after: 1 month X-MFC-with: r321369
|
323112 |
01-Sep-2017 |
dim |
Upgrade our copies of clang, llvm, lldb and compiler-rt to r312293 from the upstream release_50 branch. This corresponds to 5.0.0 rc4.
As of this version, the cad/stepcode port should now compile in a more reasonable time on i386 (see bug 221836 for more information).
PR: 221836 MFC after: 2 months X-MFC-with: r321369
|
322855 |
24-Aug-2017 |
dim |
Upgrade our copies of clang, llvm, lldb and compiler-rt to r311606 from the upstream release_50 branch.
As of this version, lib/msun's trig test should also work correctly again (see bug 220989 for more information).
PR: 220989 MFC after: 2 months X-MFC-with: r321369
|
322740 |
21-Aug-2017 |
dim |
Upgrade our copies of clang, llvm, lld and libc++ to r311219 from the upstream release_50 branch.
MFC after: 2 months X-MFC-with: r321369
|
322320 |
09-Aug-2017 |
dim |
Upgrade our copies of clang, llvm and libc++ to r310316 from the upstream release_50 branch.
MFC after: 2 months X-MFC-with: r321369
|
321723 |
30-Jul-2017 |
dim |
Upgrade our copies of clang, llvm, lld and lldb to r309439 from the upstream release_50 branch. This is just after upstream's 5.0.0-rc1.
MFC after: 2 months X-MFC-with: r321369
|
321664 |
28-Jul-2017 |
dim |
Pull in r308891 from upstream llvm trunk (by Benjamin Kramer):
[CodeGenPrepare] Cut off FindAllMemoryUses if there are too many uses.
This avoids excessive compile time. The case I'm looking at is Function.cpp from an old version of LLVM that still had the giant memcmp string matcher in it. Before r308322 this compiled in about 2 minutes, after it, clang takes infinite* time to compile it. With this patch we're at 5 min, which is still bad but this is a pathological case.
The cut off at 20 uses was chosen by looking at other cut-offs in LLVM for user scanning. It's probably too high, but does the job and is very unlikely to regress anything.
Fixes PR33900.
* I'm impatient and aborted after 15 minutes, on the bug report it was killed after 2h.
Pull in r308986 from upstream llvm trunk (by Simon Pilgrim):
[X86][CGP] Reduce memcmp() expansion to 2 load pairs (PR33914)
D35067/rL308322 attempted to support up to 4 load pairs for memcmp inlining which resulted in regressions for some optimized libc memcmp implementations (PR33914).
Until we can match these more optimal cases, this patch reduces the memcmp expansion to a maximum of 2 load pairs (which matches what we do for -Os).
This patch should be considered for the 5.0.0 release branch as well
Differential Revision: https://reviews.llvm.org/D35830
These fix a hang (or extremely long compile time) when building older LLVM ports.
Reported by: antoine PR: 219139
|
321369 |
22-Jul-2017 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.0 (trunk r308421). Upstream has branched for the 5.0.0 release, which should be in about a month. Please report bugs and regressions, so we can get them into the release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
MFC after: 2 months
|
318906 |
25-May-2017 |
dim |
Pull in r303257 from upstream llvm trunk (by Krzysztof Parzyszek)
[PPC] Properly update register save area offsets
The variables MinGPR/MinG8R were not updated properly when resetting the offsets, which in the included testcase lead to saving the CR register in the same location as R30.
This fixes another issue reported in PR26519.
Differential Revision: https://reviews.llvm.org/D33017
Reported by: Mark Millard PR: 206990 MFC after: 3 days
|
318655 |
22-May-2017 |
dim |
Pull in r302416 from upstream llvm trunk (by Martin Storsjö):
[ARM] Clear the constant pool cache on explicit .ltorg directives
Multiple ldr pseudoinstructions with the same constant value will reuse the same constant pool entry. However, if the constant pool is explicitly flushed with a .ltorg directive, we should not try to reference constants in the previous pool any longer, since they may be out of range.
This fixes assembling hand-written assembler source which repeatedly loads the same constant value, across a binary size larger than the pc-relative fixup range for ldr instructions (4096 bytes). Such assembler source already uses explicit .ltorg instructions to emit constant pools with regular intervals. However if we try to reuse constants emitted in earlier pools, they end up out of range.
This makes the output of the testcase match what binutils gas does (prior to this patch, it would fail to assemble).
Differential Revision: https://reviews.llvm.org/D32847
This should fix "out of range pc-relative fixup value" errors, when compiling certain ARM inline assembly for www/webkit-gtk[23].
Reported by: mmel MFC after: 3 days
|
317810 |
04-May-2017 |
dim |
Pull in r302183 from upstream llvm trunk (by Krzysztof Parzyszek):
[PPC] When restoring R30 (PIC base pointer), mark it as <def>
This happened on the PPC32/SVR4 path and was discovered when building FreeBSD on PPC32. It was a typo-class error in the frame lowering code.
This fixes PR26519.
Reported by: Mark Millard PR: 206990 MFC after: 3 days
|
317751 |
03-May-2017 |
dim |
Pull in r301983 from upstream llvm trunk (by Tim Northover):
ARM: avoid handing a deleted node back to TableGen during ISel.
When we replaced the multiplicand the destination node might already exist. When that happens the original gets CSEd and deleted. However, it's actually used as the offset so nonsense is produced.
Should fix PR32726.
This fixes an assertion failure when building building www/firefox 53.0 for arm.
Reported by: Bob Prohaska PR: 218782 MFC after: 3 days
|
317458 |
26-Apr-2017 |
dim |
Pull in r294458 from upstream llvm trunk (by Sanne Wouda):
[Assembler] Enable nicer diagnostics for inline assembly.
Fixed test.
Summary: Enables source location in diagnostic messages from the backend. This is after parsing, during finalization. This requires the SourceMgr, the inline assembly string buffer, and DiagInfo to still be alive after EmitInlineAsm returns.
This patch creates a single SourceMgr for inline assembly inside the AsmPrinter. MCContext gets a pointer to this SourceMgr. Using one SourceMgr per call to EmitInlineAsm would make it difficult for MCContext to figure out in which SourceMgr the SMLoc is located, while a single SourceMgr can figure it out if it has multiple buffers.
The Str argument to EmitInlineAsm is copied into a buffer and owned by the inline asm SourceMgr. This ensures that DiagHandlers won't print garbage. (Clang emits a "note: instantiated into assembly here", which refers to this string.)
The AsmParser gets destroyed before finalization, which means that the DiagHandlers the AsmParser installs into the SourceMgr will be stale. Restore the saved DiagHandlers.
Since now we're using just one SourceMgr for multiple inline asm strings, we need to tell the AsmParser which buffer it needs to parse currently. Hand a buffer id -- returned from SourceMgr:: AddNewSourceBuffer -- to the AsmParser.
Reviewers: rnk, grosbach, compnerd, rengolin, rovka, anemet
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29441
This improves error reporting for some inline assembly constructs that clang does not approve of: instead of crashing with a "fatal backend error", it will now show a normal error message, and point out the location of the problematic assembly.
Reported by: mmel MFC after: 1 week
|
317079 |
18-Apr-2017 |
dim |
Pull in r300429 from upstream llvm trunk (by Benjamin Kramer):
[X86] Remove special handling for 16 bit for A asm constraints.
Our 16 bit support is assembler-only + the terrible hack that is .code16gcc. Simply using 32 bit registers does the right thing for the latter.
Fixes PR32681.
This fixes some cases of assembling 16 bit code (i.e. SeaBIOS) that uses the 'A' inline asm constraint, after r316989.
MFC after: 3 days X-MFC-With: r316989
|
316989 |
15-Apr-2017 |
dim |
Pull in r300404 from upstream llvm trunk (by me):
Use correct registers for "A" inline asm constraint
Summary: In PR32594, inline assembly using the 'A' constraint on x86_64 causes llvm to crash with a "Cannot select" stack trace. This is because `X86TargetLowering::getRegForInlineAsmConstraint` hardcodes that 'A' means the EAX and EDX registers.
However, on x86_64 it means the RAX and RDX registers, and on 16-bit x86 (ia16?) it means the old AX and DX registers.
Add new register classes in `X86RegisterInfo.td` to support these cases, and amend the logic in `getRegForInlineAsmConstraint` to cope with different subtargets. Also add a test case, derived from PR32594.
Reviewers: craig.topper, qcolombet, RKSimon, ab
Reviewed By: ab
Subscribers: ab, emaste, royger, llvm-commits
Differential Revision: https://reviews.llvm.org/D31902
This should fix crashes when using the 'A' constraint on amd64, for example as it is being used in Xen.
Reported by: royger MFC after: 3 days
|
315016 |
10-Mar-2017 |
dim |
Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release. We were already very close to the last release candidate, so this is a pretty minor update.
Relnotes: yes MFC after: 1 month X-MFC-With: r314564
|
314795 |
06-Mar-2017 |
dim |
Reapply r287232 from upstream llvm trunk (by Daniil Fukalov):
[SCEV] limit recursion depth of CompareSCEVComplexity
Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time.
Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter.
Reviewers: sanjoy
Subscribers: mzolotukhin, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D26389
Pull in r296992 from upstream llvm trunk (by Sanjoy Das):
[SCEV] Decrease the recursion threshold for CompareValueComplexity
Fixes PR32142.
r287232 accidentally increased the recursion threshold for CompareValueComplexity from 2 to 32. This change reverses that change by introducing a separate flag for CompareValueComplexity's threshold.
The latter revision fixes the excessive compile times for skein_block.c.
|
314708 |
05-Mar-2017 |
dim |
For now, revert r287232 from upstream llvm trunk (by Daniil Fukalov):
[SCEV] limit recursion depth of CompareSCEVComplexity
Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time.
Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter.
Reviewers: sanjoy
Subscribers: mzolotukhin, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D26389
This commit is the cause of excessive compile times on skein_block.c (and possibly other files) during kernel builds on amd64.
We never saw the problematic behavior described in this upstream commit, so for now it is better to revert it. An upstream bug has been filed here: https://bugs.llvm.org/show_bug.cgi?id=32142
Reported by: mjg
|
314564 |
02-Mar-2017 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 (branches/release_40 296509). The release will follow soon.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
Also note that as of 4.0.0, lld should be able to link the base system on amd64 and aarch64. See the WITH_LLD_IS_LLD setting in src.conf(5). Though please be aware that this is work in progress.
Release notes for llvm, clang and lld will be available here: <http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/4.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/4.0.0/tools/lld/docs/ReleaseNotes.html>
Thanks to Ed Maste, Jan Beich, Antoine Brodin and Eric Fiselier for their help.
Relnotes: yes Exp-run: antoine PR: 215969, 216008 MFC after: 1 month
|
312993 |
30-Jan-2017 |
dim |
Pull in r279454 from upstream llvm trunk (by James Molloy):
[SROA] Remove incorrect assertion
Confirmed with aprantl, this assertion is incorrect - code can get here (for example 80-bit FP types) and if it does it's benign. This is exposed by a completely unrelated patch of mine, so stop the compiler falling over.
Original differential: http://reviews.llvm.org/D16187 aprantl's advice to remove assertion: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160815/382129.html
This should fix assertions when building the math/opensolaris-libm port.
Reported by: marino MFC after: 3 days
|
312832 |
26-Jan-2017 |
dim |
Pull in r278160 from upstream llvm trunk (by Wei Mi):
Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion".
The fix for PR28705 will be committed consecutively.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion. However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and S1 = S2 + C_a S3 = S2 + C_b where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
Pull in r278161 from upstream llvm trunk (by Wei Mi):
Fix the runtime error caused by "Use ValueOffsetPair to enhance value reuse during SCEV expansion".
The patch is to fix the bug in PR28705. It was caused by setting wrong return value for SCEVExpander::findExistingExpansion. The return values of findExistingExpansion have different meanings when the function is used in different ways so it is easy to make mistake. The fix creates two new interfaces to replace SCEVExpander::findExistingExpansion, and specifies where each interface is expected to be used.
Differential Revision: https://reviews.llvm.org/D22942
Pull in r281439 from upstream llvm trunk (by Wei Mi):
Create a getelementptr instead of sub expr for ValueOffsetPair if the value is a pointer.
This patch is to fix PR30213. When expanding an expr based on ValueOffsetPair, if the value is of pointer type, we can only create a getelementptr instead of sub expr.
Differential Revision: https://reviews.llvm.org/D24088
This should fix assertion failures when building OpenCV >= 3.1, and also allow building lang/spidermonkey24 without any further assertions.
PR: 215649 MFC after: 1 week
|
312831 |
26-Jan-2017 |
dim |
Revert r312765 for now, since it causes assertions when building lang/spidermonkey24.
Reported by: antoine PR: 215649
|
312765 |
25-Jan-2017 |
dim |
Pull in r276136 from upstream llvm trunk (by Wei Mi):
Use ValueOffsetPair to enhance value reuse during SCEV expansion.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion. However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and S1 = S2 + C_a S3 = S2 + C_b where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
This should fix assertion failures when building OpenCV >= 3.1.
PR: 215649 MFC after: 3 days
|
310194 |
17-Dec-2016 |
dim |
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 3.9.1 release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
Release notes for llvm, clang and lld will be available here: <http://releases.llvm.org/3.9.1/docs/ReleaseNotes.html> <http://releases.llvm.org/3.9.1/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/3.9.1/tools/lld/docs/ReleaseNotes.html>
Relnotes: yes MFC after: 2 weeks X-MFC-with: r309124
|
309835 |
10-Dec-2016 |
dim |
Tentatively apply https://reviews.llvm.org/D18730 to work around gcc PR 70528 (bogus error: constructor required before non-static data member). This should fix buildworld with the external gcc package.
Reported by: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/
|
309722 |
08-Dec-2016 |
dim |
Pull in r281586 from upstream llvm trunk (by Wei Mi):
Add some shortcuts in LazyValueInfo to reduce compile time of Correlated Value Propagation.
The patch is to partially fix PR10584. Correlated Value Propagation queries LVI to check non-null for pointer params of each callsite. If we know the def of param is an alloca instruction, we know it is non-null and can return early from LVI. Similarly, CVP queries LVI to check whether pointer for each mem access is constant. If the def of the pointer is an alloca instruction, we know it is not a constant pointer. These shortcuts can reduce the cost of CVP significantly.
Differential Revision: https://reviews.llvm.org/D18066
This significantly reduces memory usage and compilation time when compiling a particular C++ source file of the graphics/colmap port.
PR: 215136 MFC after: 3 days
|
309149 |
25-Nov-2016 |
dim |
Pull in r283060 from upstream llvm trunk (by Hal Finkel):
[PowerPC] Refactor soft-float support, and enable PPC64 soft float
This change enables soft-float for PowerPC64, and also makes soft-float disable all vector instruction sets for both 32-bit and 64-bit modes. This latter part is necessary because the PPC backend canonicalizes many Altivec vector types to floating-point types, and so soft-float breaks scalarization support for many operations. Both for embedded targets and for operating-system kernels desiring soft-float support, it seems reasonable that disabling hardware floating-point also disables vector instructions (embedded targets without hardware floating point support are unlikely to have Altivec, etc. and operating system kernels desiring not to use floating-point registers to lower syscall cost are unlikely to want to use vector registers either). If someone needs this to work, we'll need to change the fact that we promote many Altivec operations to act on v4f32. To make it possible to disable Altivec when soft-float is enabled, hardware floating-point support needs to be expressed as a positive feature, like the others, and not a negative feature, because target features cannot have dependencies on the disabling of some other feature. So +soft-float has now become -hard-float.
Fixes PR26970.
Pull in r283061 from upstream clang trunk (by Hal Finkel):
[PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float
Enable soft-float support on PPC64, as the backend now supports it. Also, the backend now uses -hard-float instead of +soft-float, so set the target features accordingly.
Fixes PR26970.
Reported by: Mark Millard PR: 214433
|
309147 |
25-Nov-2016 |
dim |
Pull in r282174 from upstream llvm trunk (by Krzysztof Parzyszek):
[PPC] Set SP after loading data from stack frame, if no red zone is present
Follow-up to r280705: Make sure that the SP is only restored after all data is loaded from the stack frame, if there is no red zone.
This completes the fix for https://llvm.org/bugs/show_bug.cgi?id=26519.
Differential Revision: https://reviews.llvm.org/D24466
Reported by: Mark Millard PR: 214433
|
309124 |
24-Nov-2016 |
dim |
Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0 release, and add lld 3.9.0. Also completely revamp the build system for clang, llvm, lldb and their related tools.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
Release notes for llvm, clang and lld are available here: <http://llvm.org/releases/3.9.0/docs/ReleaseNotes.html> <http://llvm.org/releases/3.9.0/tools/clang/docs/ReleaseNotes.html> <http://llvm.org/releases/3.9.0/tools/lld/docs/ReleaseNotes.html>
Thanks to Ed Maste, Bryan Drewery, Andrew Turner, Antoine Brodin and Jan Beich for their help.
Relnotes: yes MFC after: 1 month
|
308559 |
11-Nov-2016 |
dim |
Pull in r263169 from upstream llvm trunk (by Tim Northover):
AArch64: only try to use scaled fcvt ops on legal vector types.
Before we ended up calling getSimpleVectorType on a <3 x float>, which asserted.
This fixes an assertion when building the print/ghostscript9-agpl-base port for AArch64.
PR: 213865 MFC after: 3 days
|
308487 |
10-Nov-2016 |
dim |
Pull in r263301 from upstream llvm trunk (by Ahmed Bougacha):
[AArch64] Don't blindly lower f16/f128 FCCMPs.
Instead, extend f16 (like we do when lowering a standalone SETCC), and let f128 be legalized to the RT calls.
Fixes PR26803.
This fixes a fatal "Cannot select" backend error when building the net/freerdp port for AArch64.
PR: 214380 MFC after: 3 days
|
308375 |
06-Nov-2016 |
dim |
Pull in r278002 from upstream llvm trunk (by Silviu Baranga):
[AArch64] PR28877: Don't assume we're running after legalization when creating vcvtfp2fxs
Summary: The DAG combine transformation that was generating the aarch64_neon_vcvtfp2fxs node was assuming that all inputs where legal and wasn't accounting that the input could be a v4f64 if we're trying to do the transformation before legalization. We now bail out in this case.
All illegal types besides v4f64 were already rejected.
Fixes https://llvm.org/bugs/show_bug.cgi?id=28877
Reviewers: jmolloy
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D23261
This fixes several ports on AArch64.
Requested by: andrew MFC after: 3 days
|
305218 |
01-Sep-2016 |
dim |
Pull in r277331 from upstream llvm trunk (by Diana Picus):
[AArch64] Return the correct size for TLSDESC_CALLSEQ
The branch relaxation pass is computing the wrong offsets because it assumes TLSDESC_CALLSEQ eats up 4 bytes, when in fact it is lowered to an instruction sequence taking up 16 bytes. This can become a problem in huge files with lots of TLS accesses, as it may slowly move branch targets out of the range computed by the branch relaxation pass.
Fixes PR24234 https://llvm.org/bugs/show_bug.cgi?id=24234
Differential Revision: https://reviews.llvm.org/D22870
This fixes "error in backend: fixup value out of range" when compiling the misc/talkfilters port for AArch64.
Reported by: sbruno PR: 201762 MFC after: 3 days
|
304530 |
20-Aug-2016 |
dim |
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
|
304319 |
17-Aug-2016 |
dim |
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
|
301227 |
02-Jun-2016 |
dim |
Pull in r271548 from upstream llvm trunk (by me):
Only attempt to detect AVG if SSE2 is available
Summary: In PR29973 Sanjay Patel reported an assertion failure when a certain loop was optimized, for a target without SSE2 support. It turned out this was because of the AVG pattern detection introduced in rL253952.
Prevent the assertion failure by bailing out early in `detectAVGPattern()`, if the target does not support SSE2.
Also add a minimized test case.
Reviewers: congh, eli.friedman, spatel
Subscribers: emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D20905
This should fix assertion failures ("Requires at least SSE2!") when building the games/0ad port with CPUTYPE=pentium3.
Reported by: madpilot
|
300974 |
29-May-2016 |
dim |
Pull in r269908 from upstream llvm trunk (by James Molloy):
[VectorUtils] Fix nasty use-after-free
In truncateToMinimalBitwidths() we were RAUW'ing an instruction then erasing it. However, that intruction could be cached in the map we're iterating over. The first check is "I->use_empty()" which in most cases would return true, as the (deleted) object was RAUW'd first so would have zero use count. However in some cases the object could have been polluted or written over and this wouldn't be the case. Also it makes valgrind, asan and traditionalists who don't like their compiler to crash sad.
No testcase as there are no externally visible symptoms apart from a crash if the stars align.
Fixes PR26509.
This should fix crashes when building a number of ports on arm64.
Reported by: andrew
|
298094 |
16-Apr-2016 |
gjb |
Remove svn:mergeinfo on files with which it should never have existed.
Sponsored by: The FreeBSD Foundation
|
297294 |
26-Mar-2016 |
dim |
Pull in r264465 from upstream llvm trunk (by David Majnemer):
[X86] Emit a proper ADJCALLSTACKDOWN in EmitLoweredTLSAddr
We forgot to add the second machine operand to our ADJCALLSTACKDOWN, resulting in crashes in PEI.
This fixes PR27071.
This should fix an assertion failure during buildworld, when using -Os, and targeting either i386 directly, or building the 32-bit libraries on amd64.
Reported by: Eric Camachat <eric.camachat@gmail.com>
|
296418 |
05-Mar-2016 |
dim |
Convert two llvm source files to native line ending, which was also done upstream. Merging doesn't automatically do this, unfortunately.
|
296417 |
05-Mar-2016 |
dim |
Upgrade our copies of clang, llvm, lldb and compiler-rt to 3.8.0 release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
Release notes for llvm and clang will soon be available here: <http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html> <http://llvm.org/releases/3.8.0/tools/clang/docs/ReleaseNotes.html>
Thanks to Ed Maste, Roman Divacky, Davide Italiano and Antoine Brodin for their help.
Relnotes: yes
|
292735 |
25-Dec-2015 |
dim |
Upgrade our copies of clang and llvm to 3.7.1 release. This is a bugfix-only release, with no new features.
Please note that from 3.5.0 onwards, clang and llvm require C++11 support to build; see UPDATING for more information.
|
290494 |
07-Nov-2015 |
bapt |
Improve collation string and locales support
Merge collation support from Illumos and DragonflyBSD.
Locales are now generated with the new localedef(1) tool from CLDR POSIX files. The generated files are now identified as "BSD 1.0" format.
The libc now only read "BSD 1.0" locales definitions, all other version will be set to "C" The localedef(1) tool has been imported from Illumos and modified to use tree(3) instead of the CDDL avl(3) A set of tool created by edwin@ and extended by marino@ for dragonfly has been added to be able to generate locales and the Makefiles from the vanilla CLDR unicode databases + a universal UTF-8 charmap (by marino@) Update the locales to unicode v27 Given our regex(3) does not support multibyte (yet) it has been forced to always use locale C Remove now unused colldef(1) and mklocale(1) Finish implementing the numeric BSD extension for ctypes The number of supported locales has grown from 175 to 250 locales. Among the new locales: 6 Arabic locales (AE EG JO MA QA SA), Different variations of spanish locales. Added new 3 components locales for mn_Cyrl_MN, sr_Cyrl_RS sr_Latn_RS, zh_Hans_CN, zh_Hant_HK and zh_Hant_TW. Some aliases has been for 2 components version when possible.
Thanks: Garrett D'Amore (Illumos) who made sure all his work was done under BSD license!, Edwin Groothuis (edwin@) for the work he made on tools to be able to generate locales definition usable in freebsd sources out of vanilla CLDR definitions, John Marino (DragonflyBSD) who first merge the Illumos work into Dragonfly and spent hours tracking down bugs.
|
290102 |
28-Oct-2015 |
bapt |
Merge mpsutil(8) branch
mpsutil(8)/mprutil(8) are new utilities for managing LSI Fusion-MPT 2/3 controllers (mps(4) and mpr(4))
For now only informational commands have been implemented.
This utility has been written by scottl@ [1] and polished by myself[2]
Submitted by: scottl Discussed with: scottl Relnotes: yes Sponsored by: Netflix [1] Sponsored by: Gandi.net [2]
|
289221 |
13-Oct-2015 |
dim |
Pull in r250085 from upstream llvm trunk (by Andrea Di Biagio):
[x86] Fix wrong lowering of vsetcc nodes (PR25080).
Function LowerVSETCC (in X86ISelLowering.cpp) worked under the wrong assumption that for non-AVX512 targets, the source type and destination type of a type-legalized setcc node were always the same type.
This assumption was unfortunately incorrect; the type legalizer is not always able to promote the return type of a setcc to the same type as the first operand of a setcc.
In the case of a vsetcc node, the legalizer firstly checks if the first input operand has a legal type. If so, then it promotes the return type of the vsetcc to that same type. Otherwise, the return type is promoted to the 'next legal type', which, for vectors of MVT::i1 is always a 128-bit integer vector type.
Example (-mattr=+avx):
%0 = trunc <8 x i32> %a to <8 x i23> %1 = icmp eq <8 x i23> %0, zeroinitializer
The initial selection dag for the code above is:
v8i1 = setcc t5, t7, seteq:ch t5: v8i23 = truncate t2 t2: v8i32,ch = CopyFromReg t0, Register:v8i32 %vreg1 t7: v8i32 = build_vector of all zeroes.
The type legalizer would firstly check if 't5' has a legal type. If so, then it would reuse that same type to promote the return type of the setcc node. Unfortunately 't5' is of illegal type v8i23, and therefore it cannot be used to promote the return type of the setcc node. Consequently, the setcc return type is promoted to v8i16. Later on, 't5' is promoted to v8i32 thus leading to the following dag node: v8i16 = setcc t32, t25, seteq:ch
where t32 and t25 are now values of type v8i32.
Before this patch, function LowerVSETCC would have wrongly expanded the setcc to a single X86ISD::PCMPEQ. Surprisingly, ISel was still able to match an instruction. In our case, ISel would have matched a VPCMPEQWrr: t37: v8i16 = X86ISD::VPCMPEQWrr t36, t25
However, t36 and t25 are both VR256, while the result type is instead of class VR128. This inconsistency ended up causing the insertion of COPY instructions like this: %vreg7<def> = COPY %vreg3; VR128:%vreg7 VR256:%vreg3
Which is an invalid full copy (not a sub register copy). Eventually, the backend would have hit an UNREACHABLE "Cannot emit physreg copy instruction" in the attempt to expand the malformed pseudo COPY instructions.
This patch fixes the problem adding the missing logic in LowerVSETCC to handle the corner case of a setcc with 128-bit return type and 256-bit operand type.
This problem was originally reported by Dimitry as PR25080. It has been latent for a very long time. I have added the minimal reproducible from that bugzilla as test setcc-lowering.ll.
Differential Revision: http://reviews.llvm.org/D13660
This should fix the "Cannot emit physreg copy instruction" errors when compiling contrib/wpa/src/common/ieee802_11_common.c, and CPUTYPE is set to a CPU supporting AVX (e.g. sandybridge, ivybridge).
|
289072 |
09-Oct-2015 |
dim |
Temporarily revert upstream llvm trunk r240144 (by Michael Zolotukhin):
[SLP] Vectorize for all-constant entries.
This should fix libc++'s iostream initialization SIGBUSing on amd64, whenever the global cout symbol is not aligned to 16 bytes.
Some further explanation: libc++'s iostream.cpp contains the definitions of std::cout, std::cerr and so on. These global objects are effectively declared with an alignment of 8 bytes. When an executable is linked against libc++.so, it can sometimes get a copy of the global object, which is then at the same alignment.
However, with clang 3.7.0, the initialization of these global objects will incorrectly use SSE instructions (e.g. movdqa), whenever the optimization level is high enough, and SSE is enabled, such as on amd64. When any of these objects is not aligned to 16 bytes, this will result in a SIGBUS during iostream initialization. In contrast, clang 3.6.x and earlier took the 8 byte alignment into consideration, and avoided SSE for those particular operations.
After bisecting of upstream changes, I found that the above revision caused the change of this behavior, so I am reverting it now as a workaround, while a discussion and test case is being prepared for upstream.
|
288943 |
06-Oct-2015 |
dim |
Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.7.0 release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html> <http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html>
Thanks to Ed Maste, Andrew Turner and Antoine Brodin for their help.
Exp-run: antoine Relnotes: yes
|
285149 |
04-Jul-2015 |
dim |
Pull in r241142 from upstream llvm trunk (by David Majnemer):
[SCCP] Turn loads of null into undef instead of zero initialized values
Surprisingly, this is a correctness issue: the mmx type exists for calling convention purposes, LLVM doesn't have a zero representation for them.
This partially fixes PR23999.
Pull in r241143 from upstream llvm trunk (by David Majnemer):
[LoopUnroll] Use undef for phis with no value live
We would create a phi node with a zero initialized operand instead of undef in the case where no value was originally available. This was problematic for x86_mmx which has no null value.
These fix a "Cannot create a null constant of that type!" error when compiling the graphics/sdl2_gfx port with MMX enabled.
Reported by: amdmi3
|
283526 |
25-May-2015 |
dim |
Upgrade our copy of clang and llvm to 3.6.1 release.
This release contains the following cherry-picked revisions from upstream trunk:
226124 226151 226164 226165 226166 226407 226408 226409 226652 226905 226983 227084 227087 227089 227208 227209 227210 227211 227212 227213 227214 227269 227430 227482 227503 227519 227574 227822 227986 227987 227988 227989 227990 228037 228038 228039 228040 228188 228189 228190 228273 228372 228373 228374 228403 228765 228848 228918 229223 229225 229226 229227 229228 229230 229234 229235 229236 229238 229239 229413 229507 229680 229750 229751 229752 229911 230146 230147 230235 230253 230255 230469 230500 230564 230603 230657 230742 230748 230956 231219 231237 231245 231259 231280 231451 231563 231601 231658 231659 231662 231984 231986 232046 232085 232142 232176 232179 232189 232382 232386 232389 232425 232438 232443 232675 232786 232797 232943 232957 233075 233080 233351 233353 233409 233410 233508 233584 233819 233904 234629 234636 234891 234975 234977 235524 235641 235662 235931 236099 236306 236307
Please note that from 3.5.0 onwards, clang and llvm require C++11 support to build; see UPDATING for more information.
|
281775 |
20-Apr-2015 |
dim |
Pull in r229911 from upstream llvm trunk (by Benjamin Kramer):
MC: Allow multiple comma-separated expressions on the .uleb128 directive.
For compatiblity with GNU as. Binutils documents this as '.uleb128 expressions'. Subtle, isn't it?
Reported by: sbruno PR: 199554 MFC after: 3 days
|
280865 |
30-Mar-2015 |
emaste |
llvm: Backport upstream r229195 to fix arm64 TLS relocations
As is described at http://llvm.org/bugs/show_bug.cgi?id=22408, the GNU linkers ld.bfd and ld.gold currently only support a subset of the whole range of AArch64 ELF TLS relocations. Furthermore, they assume that some of the code sequences to access thread-local variables are produced in a very specific sequence. When the sequence is not as the linker expects, it can silently mis-relaxe/mis-optimize the instructions. Even if that wouldn't be the case, it's good to produce the exact sequence, as that ensures that linkers can perform optimizing relaxations.
This patch:
* implements support for 16MiB TLS area size instead of 4GiB TLS area size. Ideally clang would grow an -mtls-size option to allow support for both, but that's not part of this patch. * by default doesn't produce local dynamic access patterns, as even modern ld.bfd and ld.gold linkers do not support the associated relocations. An option (-aarch64-elf-ldtls-generation) is added to enable generation of local dynamic code sequence, but is off by default. * makes sure that the exact expected code sequence for local dynamic and general dynamic accesses is produced, by making use of a new pseudo instruction. The patch also removes two (AArch64ISD::TLSDESC_BLR, AArch64ISD::TLSDESC_CALL) pre-existing AArch64-specific pseudo SDNode instructions that are superseded by the new one (TLSDESC_CALLSEQ).
Submitted by: Kristof Beyls Differential Revision: https://reviews.freebsd.org/D2175
|
280400 |
23-Mar-2015 |
dim |
Pull in r230348 from upstream llvm trunk (by Tim Northover):
ARM: treat [N x i32] and [N x i64] as AAPCS composite types
The logic is almost there already, with our special homogeneous aggregate handling. Tweaking it like this allows front-ends to emit AAPCS compliant code without ever having to count registers or add discarded padding arguments.
Only arrays of i32 and i64 are needed to model AAPCS rules, but I decided to apply the logic to all integer arrays for more consistency.
This fixes a possible "Unexpected member type for HA" error when compiling lib/msun/bsdsrc/b_tgamma.c for armv6.
Reported by: Jakub Palider <jpa@semihalf.com>
|
280031 |
15-Mar-2015 |
dim |
Upgrade our copy of clang, llvm and lldb to 3.6.0 release.
Please note that from 3.5.0 onwards, clang/llvm/lldb require C++11 support to build; see UPDATING for more information.
Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.6.0/docs/ReleaseNotes.html> <http://llvm.org/releases/3.6.0/tools/clang/docs/ReleaseNotes.html>
Thanks to Ed Maste for the lldb part of this upgrade.
Exp-run: antoine
|
279161 |
22-Feb-2015 |
dim |
Pull in r230058 from upstream llvm trunk (by Benjamin Kramer):
LoopRotate: When reconstructing loop simplify form don't split edges from indirectbrs.
Yet another chapter in the endless story. While this looks like we leave the loop in a non-canonical state this replicates the logic in LoopSimplify so it doesn't diverge from the canonical form in any way.
http://llvm.org/PR21968
This fixes a "Cannot split critical edge from IndirectBrInst" assertion failure when building the devel/radare2 port.
PR: 195480, 196987 MFC after: 3 days
|
278361 |
07-Feb-2015 |
dim |
Back out r278349 and r278350 for now, since this apparently blows up the kernel build in sys/dev/hptmv/hptproc.c for some people.
Reported by: sbruno, Matthew Fuller <fullermd@over-yonder.net>
|
278349 |
07-Feb-2015 |
dim |
Pull in r224884 from upstream llvm trunk (by Keno Fischer):
[FastIsel][X86] Fix invalid register replacement for bool args
Summary: Consider the following IR:
%3 = load i8* undef %4 = trunc i8 %3 to i1 %5 = call %jl_value_t.0* @foo(..., i1 %4, ...) ret %jl_value_t.0* %5
Bools (that are the result of direct truncs) are lowered as whatever the argument to the trunc was and a "and 1", causing the part of the MBB responsible for this argument to look something like this:
%vreg8<def,tied1> = AND8ri %vreg7<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg8,%vreg7
Later, when the load is lowered, it will insert
%vreg15<def> = MOV8rm %vreg14, 1, %noreg, 0, %noreg; mem:LD1[undef] GR8:%vreg15 GR64:%vreg14
but remember to (at the end of isel) replace vreg7 by vreg15. Now for the bug. In fast isel lowering, we mistakenly mark vreg8 as the result of the load instead of the trunc. This adds a fixup to have vreg8 replaced by whatever the result of the load is as well, so we end up with
%vreg15<def,tied1> = AND8ri %vreg15<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg15
which is an SSA violation and causes problems later down the road.
This fixes PR21557.
Test Plan: Test test case from PR21557 is added to the test suite.
Reviewers: ributzka
Reviewed By: ributzka
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6245
This fixes a possible assertion failure when compiling toolbox.cxx from LibreOffice 4.3.5.
Reported by: kwm
|
277774 |
26-Jan-2015 |
dim |
Pull in r226664 from upstream llvm trunk (by Tim Northover):
AArch64: add backend option to reserve x18 (platform register)
AAPCS64 says that it's up to the platform to specify whether x18 is reserved, and a first step on that way is to add a flag controlling it.
From: Andrew Turner <andrew@fubar.geek.nz>
Requested by: andrew
|
277320 |
18-Jan-2015 |
dim |
Upgrade our copy of clang and llvm to 3.5.1 release. This is a bugfix only release, no new features have been added.
Please note that this version requires C++11 support to build; see UPDATING for more information.
Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.5.1/docs/ReleaseNotes.html> <http://llvm.org/releases/3.5.1/tools/clang/docs/ReleaseNotes.html>
MFC after: 1 month X-MFC-With: 276479
|
276786 |
07-Jan-2015 |
dim |
Pull in r222292 from upstream llvm trunk (by Weiming Zhao):
[Aarch64] Customer lowering of CTPOP to SIMD should check for NEON availability
This ensures llvm's AArch64 backend does not emit floating point instructions if they are disabled.
|
276537 |
02-Jan-2015 |
dim |
Pull in r222587 from upstream llvm trunk (by Jörg Sonnenberger):
Fix transformation of add with pc argument to adr for non-immediate arguments.
This fixes an "Unimplemented" error when assembling certain ARM add instructions with pc-relative arguments.
Reported by: sbruno PR: 196412, 196423
|
276479 |
31-Dec-2014 |
dim |
Upgrade our copy of clang, llvm and lldb to 3.5.0 release.
Please note that this version now requires C++11 support to build; see UPDATING for more information.
Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.5.0/docs/ReleaseNotes.html> <http://llvm.org/releases/3.5.0/tools/clang/docs/ReleaseNotes.html>
Thanks to Ed Maste, Roman Divacky, Andrew Turner, Justin Hibbits and Antoine Brodin for their invaluable help with this import.
Approved by: portmgr (antoine) MFC after: 1 month
|
275633 |
09-Dec-2014 |
dim |
Pull in r223171 from upstream llvm trunk (by Michael Zolotukhin):
PR21302. Vectorize only bottom-tested loops.
rdar://problem/18886083
This fixes a bug in the llvm vectorizer, which could sometimes cause vectorized loops to perform an additional iteration, leading to possible buffer overruns. Symptoms of this, which are usually segfaults, were first noticed when building gcc ports, here:
https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095466.html https://lists.freebsd.org/pipermail/freebsd-toolchain/2014-September/001211.html
Since this fix is very important for ports, bump __FreeBSD_version to make it easier for port maintainers to test whether the fix has been applied.
Upstream PR: http://llvm.org/PR21302 MFC after: 3 days
|
274483 |
13-Nov-2014 |
dim |
The fix imported into llvm in r274442 contains some C++11 constructs, which gcc in base cannot handle. Replace these with C++98 equivalents.
While here, add the patch for the adapted fix.
Reported by: bz, kib Pointy hat to: dim MFC after: 1 week X-MFC-With: r274442
|
274442 |
12-Nov-2014 |
dim |
Pull in r221709 from upstream llvm trunk (by Frédéric Riss):
Totally forget deallocated SDNodes in SDDbgInfo.
What would happen before that commit is that the SDDbgValues associated with a deallocated SDNode would be marked Invalidated, but SDDbgInfo would keep a map entry keyed by the SDNode pointer pointing to this list of invalidated SDDbgNodes. As the memory gets reused, the list might get wrongly associated with another new SDNode. As the SDDbgValues are cloned when they are transfered, this can lead to an exponential number of SDDbgValues being produced during DAGCombine like in http://llvm.org/bugs/show_bug.cgi?id=20893
Note that the previous behavior wasn't really buggy as the invalidation made sure that the SDDbgValues won't be used. This commit can be considered a memory optimization and as such is really hard to validate in a unit-test.
This should fix abnormally large memory usage and resulting OOM crashes when compiling certain ports with debug information.
Reported by: Dmitry Marakasov <amdmi3@amdmi3.ru> Upstream PRs: http://llvm.org/PR19031 http://llvm.org/PR20893 MFC after: 1 week
|
274286 |
08-Nov-2014 |
dim |
Pull in r201784 from upstream llvm trunk (by Benjamin Kramer):
AsmParser: Disable Darwin-style macro argument expansion on non-darwin targets.
There is code in the wild that relies on $0 not being expanded.
This fixes some cases of using $ signs in literals being incorrectly assembled.
Reported by: Richard Henderson Upstream PR: http://llvm.org/PR21500 MFC after: 3 days
|
271597 |
14-Sep-2014 |
dim |
Pull in r217410 from upstream llvm trunk (by Bob Wilson):
Set trunc store action to Expand for all X86 targets.
When compiling without SSE2, isTruncStoreLegal(F64, F32) would return Legal, whereas with SSE2 it would return Expand. And since the Target doesn't seem to actually handle a truncstore for double -> float, it would just output a store of a full double in the space for a float hence overwriting other bits on the stack.
Patch by Luqman Aden!
This should fix clang -O0 on i386 assigning garbage to floats, in certain scenarios.
PR: 187437 Submitted by: cebd@gmail.com Obtained from: http://llvm.org/viewvc/llvm-project?rev=217410&view=rev MFC after: 3 days
|
271030 |
03-Sep-2014 |
sbruno |
Apparently, the patch commited in svn r271029 doesn't actually do anyting, so we still need to modify the code in place. Pointed out by emaste.
MFC after: 2 days Relnotes: yes
|
271029 |
03-Sep-2014 |
sbruno |
Do not direct commit to contrib/llvm. Make the change a patch file instead. Reverts 271025 but still functionally patches it. Original intent is still the same. Pointed out by rdivacky.
MFV: Only emit movw on ARMv6T2
Building for the FreeBSD default target ARMv6 was emitting movw ASM on certain test cases (found building qmake4/5 for ARM). Don't do that, moreover, the AS in base doesn't understand this instruction for this target. One would need to use --integrated-as to get this to build if desired.
http://llvm.org/viewvc/llvm-project?view=revision&revision=216989
Submitted by: ian Reviewed by: dim Obtained from: llvm.org MFC after: 2 days Relnotes: yes
|
271025 |
03-Sep-2014 |
sbruno |
MFV: Only emit movw on ARMv6T2
Building for the FreeBSD default target ARMv6 was emitting movw ASM on certain test cases (found building qmake4/5 for ARM). Don't do that, moreover, the AS in base doesn't understand this instruction for this target. One would need to use --integrated-as to get this to build if desired.
http://llvm.org/viewvc/llvm-project?view=revision&revision=216989
Submitted by: ian Reviewed by: dim Obtained from: llvm.org MFC after: 2 days
|
270147 |
18-Aug-2014 |
rdivacky |
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
|
268003 |
28-Jun-2014 |
dim |
Fix breakage after r267981.
Pointy hat to: dim MFC after: 3 days X-MFC-With: r267981
|
267981 |
27-Jun-2014 |
dim |
Pull in r211627 from upstream llvm trunk (by Bill Schmidt):
[PPC64] Fix PR20071 (fctiduz generated for targets lacking that instruction)
PR20071 identifies a problem in PowerPC's fast-isel implementation for floating-point conversion to integer. The fctiduz instruction was added in Power ISA 2.06 (i.e., Power7 and later). However, this instruction is being generated regardless of which 64-bit PowerPC target is selected.
The intent is for fast-isel to punt to DAG selection when this instruction is not available. This patch implements that change. For testing purposes, the existing fast-isel-conversion.ll test adds a RUN line for -mcpu=970 and tests for the expected code generation. Additionally, the existing test fast-isel-conversion-p5.ll was found to be incorrectly expecting the unavailable instruction to be generated. I've removed these test variants since we have adequate coverage in fast-isel-conversion.ll.
This is needed to compile clang with debug+asserts on older powerpc64 and ppc970 targets.
Requested by: jhibbits MFC after: 3 days
|
267704 |
21-Jun-2014 |
dim |
Pull in r211435 from upstream llvm trunk (by Benjamin Kramer):
Legalizer: Add support for splitting insert_subvectors.
We handle this by spilling the whole thing to the stack and doing the insertion as a store.
PR19492. This happens in real code because the vectorizer creates v2i128 when AVX is enabled.
This fixes a "fatal error: error in backend: Do not know how to split the result of this operator!" message encountered during compilation of the net-p2p/libtorrent-rasterbar port.
Reported by: Evgeniy <iron@mail.ua> MFC after: 3 days
|
265925 |
12-May-2014 |
dim |
Upgrade our copy of llvm/clang to 3.4.1 release. This release contains mostly fixes, for the following upstream bugs:
http://llvm.org/PR16365 http://llvm.org/PR17473 http://llvm.org/PR18000 http://llvm.org/PR18068 http://llvm.org/PR18102 http://llvm.org/PR18165 http://llvm.org/PR18260 http://llvm.org/PR18290 http://llvm.org/PR18316 http://llvm.org/PR18460 http://llvm.org/PR18473 http://llvm.org/PR18515 http://llvm.org/PR18526 http://llvm.org/PR18600 http://llvm.org/PR18762 http://llvm.org/PR18773 http://llvm.org/PR18860 http://llvm.org/PR18994 http://llvm.org/PR19007 http://llvm.org/PR19010 http://llvm.org/PR19033 http://llvm.org/PR19059 http://llvm.org/PR19144 http://llvm.org/PR19326
MFC after: 2 weeks
|
264826 |
23-Apr-2014 |
emaste |
Merge LLVM r202188:
Debug info: Support variadic functions. Variadic functions have an unspecified parameter tag after the last argument. In IR this is represented as an unspecified parameter in the subroutine type.
Paired commit with CFE r202185.
rdar://problem/13690847
This re-applies r202184 + a bugfix in DwarfDebug's argument handling.
This merge includes a change to use the LLVM 3.4 API in lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:
DwarfUnit -> CompileUnit
Sponsored by: DARPA, AFRL
|
263313 |
18-Mar-2014 |
dim |
Pull in r203311 from upstream llvm trunk (by Arnold Schwaighofer):
ISel: Make VSELECT selection terminate in cases where the condition type has to be split and the result type widened.
When the condition of a vselect has to be split it makes no sense widening the vselect and thereby widening the condition. We end up in an endless loop of widening (vselect result type) and splitting (condition mask type) doing this. Instead, split both the condition and the vselect and widen the result.
I ran this over the test suite with i686 and mattr=+sse and saw no regressions.
Fixes PR18036.
With this fix the original problem case from the graphics/rawtherapee port (posted in http://llvm.org/PR18036 ) now compiles within ~97MB RSS.
Reported by: mandree MFC after: 1 week
|
263312 |
18-Mar-2014 |
dim |
Pull in r196939 from upstream llvm trunk (by Reid Kleckner):
Reland "Fix miscompile of MS inline assembly with stack realignment"
This re-lands commit r196876, which was reverted in r196879.
The tests have been fixed to pass on platforms with a stack alignment larger than 4.
Update to clang side tests will land shortly.
Pull in r196986 from upstream llvm trunk (by Reid Kleckner):
Revert the backend fatal error from r196939
The combination of inline asm, stack realignment, and dynamic allocas turns out to be too common to reject out of hand.
ASan inserts empy inline asm fragments and uses aligned allocas. Compiling any trivial function containing a dynamic alloca with ASan is enough to trigger the check.
XFAIL the test cases that would be miscompiled and add one that uses the relevant functionality.
Pull in r202930 from upstream llvm trunk (by Hans Wennborg):
Check for dynamic allocas and inline asm that clobbers sp before building selection dag (PR19012)
In X86SelectionDagInfo::EmitTargetCodeForMemcpy we check with MachineFrameInfo to make sure that ESI isn't used as a base pointer register before we choose to emit rep movs (which clobbers esi).
The problem is that MachineFrameInfo wouldn't know about dynamic allocas or inline asm that clobbers the stack pointer until SelectionDAGBuilder has encountered them.
This patch fixes the problem by checking for such things when building the FunctionLoweringInfo.
Differential Revision: http://llvm-reviews.chandlerc.com/D2954
Together, these commits fix the problem encountered in the devel/emacs port on the i386 architecture, where a combination of stack realignment, alloca() and memcpy() could incidentally clobber the %esi register, leading to segfaults in the temacs build-time utility.
See also: http://llvm.org/PR18171 and http://llvm.org/PR19012
Reported by: ashish PR: ports/183064 MFC after: 1 week
|
262985 |
10-Mar-2014 |
dim |
Repair a few minor mismerges from r262261 in the clang-sparc64 project branch. This is also to minimize differences with upstream.
MFC after: 3 weeks X-MFC-With: r262613
|
262613 |
28-Feb-2014 |
dim |
Merge the projects/clang-sparc64 branch back to head. This brings in several updates from the llvm and clang trunks to make the sparc64 backend fully functional.
Apart from one patch to sys/sparc64/include/pcpu.h which is still under discussion, this makes it possible to let clang fully build world and kernel for sparc64.
Any assistance with testing this on actual sparc64 hardware is greatly appreciated, as there will unavoidably be bugs left.
Many thanks go to Roman Divacky for his upstream work on getting the sparc64 backend into shape.
MFC after: 1 month
|
262611 |
28-Feb-2014 |
dim |
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty when PWD can't be determined. This way, MCJIT clients, and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done only for clients of getCompilationDir(). This is as simple as checking for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which won't conceivably run with an invalid working dir. However, in the purely hypothetically and untestable case that this happens, the AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox, when it is using jails, and sometimes invalidates clang's current working directory.
Reported by: decke MFC after: 2 weeks X-MFC-With: r261991
|
261991 |
16-Feb-2014 |
dim |
Upgrade our copy of llvm/clang to 3.4 release. This version supports all of the features in the current working draft of the upcoming C++ standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The PowerPC backend has made several major improvements to code generation quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ backends have all seen major feature work.
Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.4/docs/ReleaseNotes.html> <http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC after: 1 month
|
261162 |
25-Jan-2014 |
dim |
Pull in r195679 from upstream llvm trunk:
Don't use nopl in cpus that don't support it.
Patch by Mikulas Patocka. I added the test. I checked that for cpu names that gas knows about, it also doesn't generate nopl.
The modified cpus: i686 - there are i686-class CPUs that don't have nopl: Via c3, Transmeta Crusoe, Microsoft VirtualBox - see https://bbs.archlinux.org/viewtopic.php?pid=775414 k6, k6-2, k6-3, winchip-c6, winchip2 - these are 586-class CPUs via c3 c3-2 - see https://bugs.archlinux.org/task/19733 as a proof that Via c3 and c3-Nehemiah don't have nopl
PR: bin/185777 MFC after: 3 days
|
259888 |
25-Dec-2013 |
dim |
Pull in r183971 from upstream llvm trunk:
X86: cvtpi2ps is just an SSE instruction with MMX operands. It has no AVX equivalent.
Give it the right register format so we can also emit it when AVX is enabled.
This should fix a "Cannot select: intrinsic %llvm.x86.sse.cvtpi2ps" fatal error in clang while building the gnuradio port for amd64.
Reported by: db MFC after: 3 days
|
258472 |
22-Nov-2013 |
dim |
Revert r258455 for now, as it apparently causes miscompilation in some situations. Until this is fully resolved, the X.org workaround in ports still needs to take place.
|
258455 |
21-Nov-2013 |
dim |
Pull in r195318 from upstream llvm trunk:
The basic problem is that some mainstream programs cannot deal with the way clang optimizes tail calls, as in this example:
int foo(void); int bar(void) { return foo(); }
where the call is transformed to:
calll .L0$pb .L0$pb: popl %eax .Ltmp0: addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp0-.L0$pb), %eax movl foo@GOT(%eax), %eax popl %ebp jmpl *%eax # TAILCALL
However, the GOT references must all be resolved at dlopen() time, and so this approach cannot be used with lazy dynamic linking (e.g. using RTLD_LAZY), which usually populates the PLT with stubs that perform the actual resolving.
This patch changes X86TargetLowering::LowerCall() to skip tail call optimization, if the called function is a global or external symbol.
This fixes problems with loading X.org driver modules, which could occur when X.org was compiled on i386 with tailcall optimization on, for which ports r312583 was committed as a workaround. After this change, the workaround can be removed.
MFC after: 3 days
|
258350 |
19-Nov-2013 |
dim |
Pull in r191896 from upstream llvm trunk:
CaptureTracking: Plug a loophole in the "too many uses" heuristic.
The heuristic was added to avoid spending too much compile time in a specially crafted test case (PR17461, PR16474) with many uses on a select or bitcast instruction can still trigger the slow case. Add a check for that case.
This only affects compile time, don't have a good way to test it.
This fixes the excessive compile time spent on a specific file of the graphics/rawtherapee port.
Reported by: mandree MFC after: 3 days
|
258005 |
11-Nov-2013 |
emaste |
Merge upstream LLVM r192118:
Formally added an explicit enum for DWARF TLS support. No functionality change.
Reviewed by: dim@ Sponsored by: DARPA, AFRL
|
256090 |
06-Oct-2013 |
dim |
Pull in r192064 from upstream llvm trunk:
X86: Don't fold spills into SSE operations if the stack is unaligned.
Regalloc can emit unaligned spills nowadays, but we can't fold the spills into SSE ops if we can't guarantee alignment. PR12250.
This fixes unaligned SSE accesses (leading to a SIGBUS) which could occur in the ffmpeg ports.
Approved by: re (kib) Reported by: tijl MFC after: 3 days
|
256030 |
03-Oct-2013 |
dim |
Pull in r189644 from upstream llvm trunk:
Add ms_abi and sysv_abi attribute handling.
Based on a patch by Benno Rice!
This will help to develop EFI support.
Approved by: re (kib) Verified by: benno MFC after: 1 week
|
256024 |
03-Oct-2013 |
dim |
Pull in r186338 from upstream llvm trunk:
Remove invalid assert in DAGTypeLegalizer::RemapValue
There is a comment at the top of DAGTypeLegalizer::PerformExpensiveChecks which, in part, says:
// Note that these invariants may not hold momentarily when processing a node: // the node being processed may be put in a map before being marked Processed.
Unfortunately, this assert would be valid only if the above-mentioned invariant held unconditionally. This was causing llc to assert when, in fact, everything was fine.
Thanks to Richard Sandiford for investigating this issue!
Fixes PR16562.
This fixes assertions which could occur in the multimedia/ffmpeg1 and multimedia/ffmpeg2 ports.
Approved by: re (hrs) Reported by: Matthias Apitz <guru@unixarea.de> MFC after: 3 days
|
255978 |
01-Oct-2013 |
dim |
Pull in r191711 from upstream llvm trunk:
The X86FixupLEAs pass for Intel Atom must not call convertToThreeAddress on ADD16rr opcodes, if src1 != src, since that would cause convertToThreeAddress to try to create a virtual register. This is not permitted after register allocation, which is when the X86FixupLEAs pass runs.
This patch fixes PR16785.
Pull in r191715 from upstream llvm trunk:
Forgot to add a break statement.
This should enable building the x11-toolskits/libXaw port with CPUTYPE=atom.
Approved by: re (gjb) Reported by: Kenta Suzumoto <kentas@hush.com> MFC after: 3 days
|
255804 |
22-Sep-2013 |
dim |
Pull in r191165 from upstream llvm trunk:
ISelDAG: spot chain cycles involving MachineNodes
Previously, the DAGISel function WalkChainUsers was spotting that it had entered already-selected territory by whether a node was a MachineNode (amongst other things). Since it's fairly common practice to insert MachineNodes during ISelLowering, this was not the correct check.
Looking around, it seems that other nodes get their NodeId set to -1 upon selection, so this makes sure the same thing happens to all MachineNodes and uses that characteristic to determine whether we should stop looking for a loop during selection.
This should fix PR15840.
Specifically, this fixes the long-standing assertion failure when compiling the multimedia/gstreamer port on i386. Thanks to Tijl Coosemans for his help in getting upstream to fix it.
Approved by: re (marius)
|
255076 |
30-Aug-2013 |
dim |
Pull in r189672 from upstream llvm trunk:
InstCombine: Check for zero shift amounts before subtracting one causing integer overflow.
PR17026. Also avoid undefined shifts and shift amounts larger than 64 bits (those are always undef because we can't represent integer types that large).
This should fix assertion failures when building the emulators/xmame port.
Reported by: bapt
|
254790 |
24-Aug-2013 |
emaste |
Import llvm r187614 (git 44c8e34), for lldb's use:
Author: Daniel Malea <daniel.malea@intel.com> Date: Thu Aug 1 21:18:16 2013 +0000
Fixed the Intel-syntax X86 disassembler to respect the (existing) option for hexadecimal immediates, to match AT&T syntax. This also brings a new option for C-vs-MASM-style hex.
Patch by Richard Mitton Reviewed: http://llvm-reviews.chandlerc.com/D1243
|
253042 |
08-Jul-2013 |
dim |
Pull in r185616 from llvm trunk:
FastISel can only append to basic blocks.
Compute the insertion point from the end of the basic block instead of skipping labels from the front.
This caused failures in landing pads when live-in copies where inserted before instruction selection.
I missed this change in r252720; without it, certain compilation flags can cause exception labels to not be generated, but still referenced, leading to link errors.
Reported by: zeising MFC after: 3 days
|
252720 |
04-Jul-2013 |
dim |
Pull in r185594 from llvm trunk:
Add MachineBasicBlock::addLiveIn().
This function adds a live-in physical register to an MBB and ensures that it is copied to a virtual register immediately.
Pull in r185615 from llvm trunk:
Live-in copies go *after* EH_LABELs.
This will soon be tested by exception handling working at all.
Pull in r185617 from llvm trunk:
Simplify landing pad lowering.
Stop using the ISD::EXCEPTIONADDR and ISD::EHSELECTION when lowering landing pad arguments. These nodes were previously legalized into CopyFromReg nodes, but that never worked properly because the CopyFromReg node weren't guaranteed to be scheduled at the top of the basic block.
This meant the exception pointer and selector registers could be clobbered before being copied to a virtual register.
This patch copies the two physical registers to virtual registers at the beginning of the basic block, and lowers the landingpad instruction directly to two CopyFromReg nodes reading the *virtual* registers. This is safe because virtual registers don't get clobbered.
A future patch will remove the ISD::EXCEPTIONADDR and ISD::EHSELECTION nodes.
Together, these changes fix llvm PR 16038 ('qt4 webcore file results in "Bad machine code: Using an undefined physical register"'), and should make it possible again to compile the www/qt4-webkit port again on the i386 arch, without using a CPUTYPE=i686 or higher setting.
|
252503 |
02-Jul-2013 |
andrew |
Work around an ARM EABI issue where clang would sometimes incorrectly align the stack in a leaf function that uses TLS.
The issue is, when using TLS, the function is no longer a leaf as it calls __aeabi_read_tp. With statically linked programs this is not an issue as it doesn't make use of the stack, however with dynamically linked applications we enter rtld which does use the stack and makes assumptions about it's alignment.
This is only a temporary fix until a better patch can be made and submitted upstream.
|
252039 |
20-Jun-2013 |
dim |
Pull in r183984 from llvm trunk:
Make PrologEpilogInserter save/restore all callee saved registers in functions which call __builtin_unwind_init()
__builtin_unwind_init() is an undocumented gcc intrinsic which has this effect, and is used in libgcc_eh.
Goes part of the way toward fixing PR8541.
This obsoletes the ugly hack to libgcc's unwind code from r245272, and should also work for other arches, so revert the hack too.
|
251761 |
14-Jun-2013 |
dim |
Pull in r181620 from llvm trunk:
[ms-inline asm] Fix a crasher when we fail on a direct match.
The issue was that the MatchingInlineAsm and VariantID args to the MatchInstructionImpl function weren't being set properly. Specifically, when parsing intel syntax, the parser thought it was parsing inline assembly in the at&t dialect; that will never be the case.
The crash was caused when the emitter tried to emit the instruction, but the operands weren't set. When parsing inline assembly we only set the opcode, not the operands, which is used to lookup the instruction descriptor. rdar://13854391 and PR15945
Also, this commit reverts r176036. Now that we're correctly parsing the intel syntax the pushad/popad don't match properly. I've reimplemented that fix using a MnemonicAlias.
Pull in r183907 from llvm trunk:
X86: Make the cmov aliases work with intel syntax too.
These commits make a number of Intel-style inline assembly mnemonics aliases (occurring in several ports) work properly, which could cause assertions otherwise.
Reported by: kwm, bapt
|
251662 |
12-Jun-2013 |
dim |
Upgrade our copy of llvm/clang to 3.3 release.
Release notes are still in the works, these will follow soon.
MFC after: 1 month
|
251431 |
05-Jun-2013 |
dim |
Pull in r183297 from upstream llvm trunk:
PR15662: Optimized debug info produces out of order function parameters
When a function is inlined we lazily construct the variables representing the function's parameters. After that, we add any remaining unused parameters.
If the function doesn't use all the parameters, or uses them out of order, then the DWARF would produce them in that order, producing a parameter order that doesn't match the source.
This fix causes us to always keep the arg variables at the start of the variable list & in the original order from the source.
Reported by: avg MFC after: 1 week
|
250997 |
26-May-2013 |
dim |
Pull in r182656 from upstream llvm trunk:
LoopVectorize: LoopSimplify can't canonicalize loops with an indirectbr in it, don't assert on those cases.
Fixes PR16139.
This should fix clang assertion failures when optimizing at -O3, similar to:
Assertion failed: (TheLoop->getLoopPreheader() && "No preheader!!"), function canVectorize, file contrib/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp, line 2171.
Reported by: O. Hartmann <ohartman@zedat.fu-berlin.de> PR: ports/178332, ports/178977 MFC after: 3 days
|
250593 |
13-May-2013 |
dim |
Pull in r181286 from upstream llvm trunk:
LoopVectorize: getConsecutiveVector must respect signed arithmetic
We were passing an i32 to ConstantInt::get where an i64 was needed and we must also pass the sign if we pass negatives numbers. The start index passed to getConsecutiveVector must also be signed.
Should fix PR15882.
This should fix Firefox crashes some people have been reporting, when it is compiled with -O3.
|
249817 |
23-Apr-2013 |
dim |
Pull in r180121 from upstream llvm trunk:
LoopVectorizer: Fix 15830. When scalarizing and unrolling stores make sure that the order in which the elements are scalarized is the same as the original order. This fixes a miscompilation in FreeBSD's regex library.
This should fix lib/libc/regex/regcomp.c at -O3 with clang 3.3 r178860 on CPUs with SSE. Before this change, the vectorizer could incorrectly rearrange the second loop in computejumps(), leading to possibly invalid entries in the re_gets::charjump table.
The net result was that for example "sed s/@CC@/foo/" failed to work correctly, leading to trouble with many configure scripts.
|
249423 |
12-Apr-2013 |
dim |
Upgrade our copy of llvm/clang to trunk r178860, in preparation of the upcoming 3.3 release (branching and freezing expected in a few weeks).
Preliminary release notes can be found at the usual location: <http://llvm.org/docs/ReleaseNotes.html>
An MFC is planned once the actual 3.3 release is finished.
|
247205 |
23-Feb-2013 |
dim |
Pull in r175962 from upstream llvm trunk:
X86: Disable cmov-memory patterns on subtargets without cmov.
Fixes PR15115.
For the i386 arch, this should enable cmov instructions only on -march=pentiumpro and higher. Since our default CPU is i486, cmov instructions will now be disabled by default.
MFC after: 1 week
|
247003 |
19-Feb-2013 |
dim |
Pull in r175360 from upstream llvm trunk:
MCParser: Reject .balign with non-pow2 alignments.
GNU as rejects them and there are configure scripts in the wild that check if the assembler rejects ".align 3" to determine whether the alignment is in bytes or powers of two.
MFC after: 3 days
|
246858 |
15-Feb-2013 |
dim |
Pull in r175057 from upstream llvm trunk:
X86: Disable generation of rep;movsl when %esi is used as a base pointer.
This happens when there is both stack realignment and a dynamic alloca in the function. If we overwrite %esi (rep;movsl uses fixed registers) we'll lose the base pointer and the next register spill will write into oblivion.
Fixes PR15249 and unbreaks firefox on i386/freebsd. Mozilla uses dynamic allocas and freebsd a 4 byte stack alignment.
MFC after: 1 week
|
245952 |
26-Jan-2013 |
pfg |
Clean some 'svn:executable' properties in the tree.
Submitted by: Christoph Mallon MFC after: 3 days
|
244628 |
23-Dec-2012 |
dim |
Upgrade our copy of llvm/clang to 3.2 release.
Release notes for llvm: http://llvm.org/releases/3.2/docs/ReleaseNotes.html
Release notes for clang: http://llvm.org/releases/3.2/tools/clang/docs/ReleaseNotes.html
MFC after: 2 weeks
|
244598 |
22-Dec-2012 |
dim |
Pull in r170353 from upstream llvm trunk:
Fix another SROA crasher, PR14601.
This was a silly oversight, we weren't pruning allocas which were used by variable-length memory intrinsics from the set that could be widened and promoted as integers. Fix that.
This should fix the following assertion failure:
Assertion failed: (CanSROA), function visitUsers, file /usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/SROA.cpp, line 2395.
Reported by: gerald
|
243830 |
03-Dec-2012 |
dim |
Upgrade our copy of llvm/clang to r168974, from upstream's release_32 branch. This is effectively llvm/clang 3.2 RC2; the 3.2 release is coming soon.
|
242835 |
09-Nov-2012 |
dim |
Reduce LLVM's default stack alignment for i386 from 16 to 4 bytes, as the FreeBSD ABI requires. This is essentially a revert of upstream llvm commit r126226, and it will be reverted by upstream too.
MFC after: 1 week
|
242380 |
30-Oct-2012 |
dim |
Pull in r165377 from upstream llvm trunk:
X86: fcmov doesn't handle all possible EFLAGS, fall back to a branch for the others.
Otherwise it will try to use SSE patterns and fail horribly if sse is disabled.
Fixes PR14035.
This should fix the following assertion failure:
Assertion failed: (Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"), function getFPReg, file contrib/llvm/lib/Target/X86/X86FloatingPoint.cpp, line 330.
which can show up when compiling contrib/compiler-rt, using -march=i686 through -march=pentium3 (CPU's which do support fcmov, but don't support SSE2).
MFC after: 1 week
|
242007 |
24-Oct-2012 |
dim |
Pull in r165367 from upstream llvm trunk:
Make sure always-inline functions get inlined. <rdar://problem/12423986>
Without this change, when the estimated cost for inlining a function with an "alwaysinline" attribute was lower than the inlining threshold, the getInlineCost function was returning that estimated cost rather than the special InlineCost::AlwaysInlineCost value. That is fine in the normal inlining case, but it can fail when the inliner considers the opportunity cost of inlining into an internal or linkonce-odr function. It may decide not to inline the always-inline function in that case. The fix here is just to make getInlineCost always return the special value for always-inline functions. I ran into this building clang with libc++. Tablegen failed to link because of an always-inline function that was not inlined. I have been unable to reduce the testcase down to a reasonable size.
This should fix the link errors that were reported when atf-run was compiled with clang -stdlib=libc++. In this case, at -O3 optimization, some calls to basic_ios::clear() were not inlined, even when the function was marked __always_inline__.
Reported by: Jan Beich <jbeich@tormail.org> MFC after: 1 week
|
241895 |
22-Oct-2012 |
dim |
Pull in r165878 from upstream llvm trunk:
X86: Disable long nops for all cpus prior to pentiumpro/i686.
This is the safest approach for now. If you think long nops matter a lot for performance, compile with -march=i686 or higher. :)
MFC after: 3 days
|
241430 |
10-Oct-2012 |
dim |
Pull in r164132 from upstream llvm trunk:
When creating MCAsmBackend pass the CPU string as well. In X86AsmBackend store this and use it to not emit long nops when the CPU is geode which doesnt support them.
Fixes PR11212.
Pull in r164133 from upstream clang trunk:
Follow up on llvm r164132.
This should prevent illegal instructions when building world on Geode CPUs (e.g. Soekris).
MFC after: 3 days
|
241427 |
10-Oct-2012 |
dim |
Pull in r163710 from upstream llvm trunk:
Add support for AMD Geode.
MFC after: 3 days
|
240531 |
15-Sep-2012 |
dim |
Pull in r163967 from upstream llvm trunk:
X86: Emitting x87 fsin/fcos for sinf/cosf is not safe without unsafe fp math.
This should make clang emit calls to libm for sinf/cosf by default.
MFC after: 1 week
|
239462 |
20-Aug-2012 |
dim |
Upgrade our copy of llvm/clang to trunk r162107. With thanks to Benjamin Kramer and Joerg Sonnenberger for their input and fixes.
|
236260 |
29-May-2012 |
dim |
Pull in r156591 from upstream llvm trunk:
Allow unique_file to take a mode for file permissions, but default to user only read/write.
and r156592 from upstream clang trunk:
For final output files create them with mode 0664 to match other compilers and expected defaults.
This should fix clang creating files with mode 0600.
Reported by: James <james@hicag.org> MFC after: 3 days
|
235864 |
23-May-2012 |
dim |
Upgrade our copy of llvm/clang to 3.1 release. Release notes can be found at: http://llvm.org/releases/3.1/docs/ReleaseNotes.html
MFC after: 3 days
|
234982 |
03-May-2012 |
dim |
Upgrade our copy of llvm/clang to r155985, from upstream's release_31 branch. This brings us very close to the 3.1 release, which is planned for May 14th.
MFC after: 2 weeks
|
234353 |
16-Apr-2012 |
dim |
Upgrade our copy of llvm/clang to trunk r154661, in preparation of the upcoming 3.1 release (expected in a few weeks). Preliminary release notes can be found at: <http://llvm.org/docs/ReleaseNotes.html>
MFC after: 2 weeks
|
230393 |
20-Jan-2012 |
dim |
Pull in r148240 from upstream llvm trunk:
Make sure the non-SSE lowering for fences correctly clobbers EFLAGS. PR11768.
In particular, this fixes segfaults during the build of devel/icu on i386. The __sync_synchronize() builtin used for implementing icu's internal barrier could lead to incorrect behaviour.
MFC after: 3 days
|
228379 |
09-Dec-2011 |
dim |
Upgrade our copy of llvm/clang to 3.0 release. Release notes can be found at: http://llvm.org/releases/3.0/docs/ReleaseNotes.html
MFC after: 1 week
|
226633 |
22-Oct-2011 |
dim |
Upgrade our copy of llvm/clang to r142614, from upstream's release_30 branch. This brings us very close to the 3.0 release, which is expected in a week or two.
MFC after: 1 week
|
225880 |
29-Sep-2011 |
dim |
Revive the LLVM and Clang license files, which were removed in my too-thorough cleanup of unused files, in r213695. Also make sure these get installed under /usr/share/doc.
Submitted by: rwatson, brooks Pointy hat to: dim MFC after: 3 days
|
224145 |
17-Jul-2011 |
dim |
Upgrade our copy of llvm/clang to r135360, from upstream's trunk.
|
223017 |
12-Jun-2011 |
dim |
Upgrade our copy of llvm/clang to r132879, from upstream's trunk.
|
221503 |
05-May-2011 |
dim |
Make cross-compiling using clang work better, by respecting the LLVM_HOSTTRIPLE that is defined during the cross-tools stage.
Using clang, you can now build amd64 world and kernel on i386, and vice versa. Other arches still need work.
|
221345 |
02-May-2011 |
dim |
Upgrade our copy of llvm/clang to r130700, from upstream's trunk.
|
219077 |
27-Feb-2011 |
dim |
Update llvm/clang to trunk r126547.
There are several bugfixes in this update, but the most important one is to ensure __start_ and __stop_ symbols for linker sets and kernel module metadata are always emitted in object files:
http://llvm.org/bugs/show_bug.cgi?id=9292
Before this fix, if you compiled kernel modules with clang, they would not be properly processed by kldxref, and if they had any dependencies, the kernel would fail to load those. Another problem occurred when attempting to mount a tmpfs filesystem, which would result in 'operation not supported by device'.
|
219076 |
27-Feb-2011 |
dim |
Instead of defining LLVM_MULTITHREADED as 0 or 1, define or undefine it, and test appropriately. Otherwise it might erroneously pick up some pthread primitives, and fail to link.
|
218893 |
20-Feb-2011 |
dim |
Upgrade our copy of llvm/clang to r126079, from upstream's trunk.
This contains many improvements, primarily better C++ support, an integrated assembler for x86 and support for -pg.
|
213695 |
11-Oct-2010 |
dim |
Remove more unneeded files and directories from contrib/llvm. This still allows us to build tblgen and clang, and further reduces the footprint in the tree.
Approved by: rpaulo (mentor)
|
213534 |
07-Oct-2010 |
dim |
Upgrade Clang and LLVM to the 2.8 release. See here for release notes: http://llvm.org/releases/2.8/docs/ReleaseNotes.html
Approved by: rpaulo (mentor)
|
212904 |
20-Sep-2010 |
dim |
Upgrade our Clang in base to r114020, from upstream's release_28 branch.
Approved-by: rpaulo (mentor)
|
210299 |
20-Jul-2010 |
ed |
Upgrade our Clang in base to r108428.
This commit merges the latest LLVM sources from the vendor space. It also updates the build glue to match the new sources. Clang's version number is changed to match LLVM's, which means /usr/include/clang/2.0 has been renamed to /usr/include/clang/2.8.
Obtained from: projects/clangbsd
|
208958 |
09-Jun-2010 |
rdivacky |
Comment out piece of code using __clear_cache() which FreeBSD does not have. This is only used for JIT on ARM so it's harmless.
Approved by: ed (mentor)
|
208954 |
09-Jun-2010 |
rdivacky |
Import LLVM/clang from vendor stripped of docs/ test/ website/ www/ examples/ in llvm/ and/or llvm/contrib/clang/ respectively.
Approved by: ed (mentor) Approved by: core
|
208599 |
27-May-2010 |
rdivacky |
Update LLVM to r104832.
|
207631 |
04-May-2010 |
rdivacky |
Update LLVM to r103052.
|
207618 |
04-May-2010 |
rdivacky |
Update LLVM to r103004.
|
206274 |
06-Apr-2010 |
rdivacky |
Update LLVM to r100520.
|
206124 |
03-Apr-2010 |
rdivacky |
Update LLVM to r100285.
|
206083 |
02-Apr-2010 |
rdivacky |
Update LLVM to r100181.
|
205407 |
21-Mar-2010 |
rdivacky |
Update LLVM to r99115.
|
205218 |
16-Mar-2010 |
rdivacky |
Update LLVM to r98631.
|
204961 |
10-Mar-2010 |
rdivacky |
Update LLVM to r98164.
|
204792 |
06-Mar-2010 |
rdivacky |
Update LLVM to r97873.
|
204642 |
03-Mar-2010 |
rdivacky |
Update LLVM to 97654.
|
203954 |
16-Feb-2010 |
rdivacky |
Update LLVM to r96341.
|
202878 |
23-Jan-2010 |
rdivacky |
Update LLVM to r94309.
|
202375 |
15-Jan-2010 |
rdivacky |
Update LLVM to 93512.
|
201360 |
01-Jan-2010 |
rdivacky |
Update LLVM to 92395.
|
200581 |
15-Dec-2009 |
rdivacky |
Update LLVM to 91430.
|
199989 |
01-Dec-2009 |
rdivacky |
Update LLVM to r90226.
|
199511 |
19-Nov-2009 |
rdivacky |
Update LLVM to r89337.
|
199481 |
18-Nov-2009 |
rdivacky |
Update LLVM to r89205.
|
198953 |
05-Nov-2009 |
rdivacky |
Update LLVM to r86140.
|
198906 |
04-Nov-2009 |
rdivacky |
Delete this file.
|
198892 |
04-Nov-2009 |
rdivacky |
Update LLVM to r86025.
|
198413 |
23-Oct-2009 |
rdivacky |
This was removed upstream.
|
198396 |
23-Oct-2009 |
rdivacky |
Update LLVM to r84949.
|
198138 |
15-Oct-2009 |
rdivacky |
Delete all stale files.
|
198113 |
15-Oct-2009 |
rdivacky |
Update llvm to r84175.
|
198090 |
14-Oct-2009 |
rdivacky |
Update llvm to r84119.
|
195340 |
04-Jul-2009 |
ed |
Import LLVM 74788.
|
195098 |
27-Jun-2009 |
ed |
Import LLVM r74383.
|
194754 |
23-Jun-2009 |
ed |
Import LLVM r73984.
It seems I keep importing sources at very unlucky moments. Let's see what this revision of LLVM does.
|
194710 |
23-Jun-2009 |
ed |
Import LLVM r73954.
|
194612 |
22-Jun-2009 |
ed |
Update LLVM sources to r73879.
|
194178 |
14-Jun-2009 |
ed |
Import LLVM r73340.
|
193724 |
08-Jun-2009 |
ed |
Import LLVM r73070.
Now I'm going to stop importing code for a while. I spent a lot of time the last couple of days figuring out which LLVM commit caused g++ to miscompile, which in its turn caused Clang to miscompile the next build. I had to run `make buildworld' twice each time I bisected a revision.
|
193630 |
07-Jun-2009 |
ed |
Import LLVM r73021.
|
193574 |
06-Jun-2009 |
ed |
Import LLVM, at r72995.
We should now have support for #pragma weak.
|
193399 |
03-Jun-2009 |
ed |
Import LLVM, at r72805, which fixes PR4315 and PR4316.
Normally I'm not updating sources this often, but I want to get rid of this breakage, because right now I can't offer a proper source snapshot yet.
|
193378 |
03-Jun-2009 |
ed |
Import LLVM, at r72770.
This should fix LLVM PR4225.
|
193323 |
02-Jun-2009 |
ed |
Import LLVM, at r72732.
|