summary refs log tree commit diff
path: root/src/rustllvm
AgeCommit message (Collapse)AuthorLines
2016-10-14LLVM: Backport "[SimplifyCFG] Correctly test for unconditional branches in ↵Michael Woerister-1/+1
GetCaseResults"
2016-09-26Extend preprocessor LLVM version checks to support LLVM 4.xJake Goulding-34/+43
This doesn't actually do anything for LLVM 4.x yet, but sets the stage.
2016-09-17Up the LLVMSimonas Kazlauskas-1/+1
Fixes #36474
2016-09-04Fix incorrect LLVM Linkage enumMatt Ickstadt-0/+80
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the #[linkage=""] attribute to break. This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it. Fixes #33992
2016-09-01Fix optimization regressions for operations on [x; n]-initialized arrays.Eduard Burtescu-1/+1
2016-08-29Auto merge of #36117 - eddyb:llvm-hoist-meta, r=alexcrichtonbors-1/+1
llvm: backport "[SimplifyCFG] Hoisting invalidates metadata". Fixes #36023 by backporting @majnemer's LLVM patch fixing [the LLVM bug](https://llvm.org/bugs/show_bug.cgi?id=29163.) where SimplifyCFG hoisted instructions andkept their metadata (conditional `!nonnull` loads could kill a null check later if hoisted). r? @alexcrichton
2016-08-29llvm: backport "[SimplifyCFG] Hoisting invalidates metadata".Eduard Burtescu-1/+1
2016-08-28build llvm with systemz backend enabled, and link to related librariesJorge Aparicio-1/+8
when building rust against system llvm closes #36077
2016-08-25Fix debug line info for macro expansions. Vadim Chugunov-0/+9
Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines. In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.
2016-08-17Update LLVM to include 4 backported commits by @majnemer.Eduard Burtescu-1/+1
2016-08-10Improved checking of target's llvm_configCameron Hart-1/+1
Point llvm @bitshifter branch until PR accepted Use today's date for LLVM auto clean trigger Update LLVM submodule to point at rust-lang fork. Handle case when target is set
2016-08-06Merge branch 'master' into issue-30961Cameron Hart-375/+661
2016-08-03Support removed LLVM intrinsics by invoking its AutoUpgrade mechanism.Eduard Burtescu-0/+8
2016-08-03finish type-auditing rustllvmAriel Ben-Yehuda-40/+70
2016-08-03begin auditing the C++ types in RustWrapperAriel Ben-Yehuda-194/+322
2016-08-03audit LLVM C++ types in ArchiveWrapper and PassWrapperAriel Ben-Yehuda-59/+196
2016-08-03remove the ExecutionEngine bindingAriel Ben-Yehuda-111/+0
the code has no tests and will just bitrot by itself. this is a [breaking-change]
2016-07-29rustc: Update LLVM to the LLVM 3.9 release branchAlex Crichton-1/+1
The 3.9 release of LLVM isn't out yet, but this moves us onto that branch to start tracking it.
2016-07-29Force check of errorJan-Erik Rediger-2/+14
The passed error needs to be checked. Otherwise it will force an abort when it is deconstructed, but a success value.
2016-07-29Use C type when passing value to LLVM passJan-Erik Rediger-1/+24
Previously the C type LLVMRelocMode (available as RelocMode in Rust) was passed as is to the function. However createTargetMachine expects a Reloc::Model, which is an enum just one value short. Additionally, the function was marked as requiring Reloc::Model in the C code, but RelocMode on the Rust-side. We now use the correct C type LLVMRelocMode and convert it to an Optional<Reloc::Model> as expected by the createTargetMachine call the same the original LLVMCreateTargetMachine function does. See https://github.com/llvm-mirror/llvm/blob/c9b262bfbd5b9fb6f10749dba1465569f39bd625/lib/Target/TargetMachineC.cpp#L104-L121 This was found by @eddyb.
2016-07-29Use correct error handling typeJan-Erik Rediger-1/+1
2016-07-29Upgrade llvmJan-Erik Rediger-1/+1
2016-07-29Flip LLVM verion check clauseJan-Erik Rediger-9/+9
2016-07-29[LLVM-3.9] Use old way of getting next childJan-Erik Rediger-2/+7
This was changed back in https://github.com/rust-lang/llvm/commit/aacf2fbf
2016-07-29[LLVM-3.9] Maintain backward compatibility in ArchiverJan-Erik Rediger-0/+7
2016-07-29[LLVM-3.9] Increase PIELevelJan-Erik Rediger-1/+1
Previously, we had a PositionIndependentExecutable, now we simply choose the highest level. This should be equivalent. :cake:
2016-07-29[LLVM-3.9] Configure PIE at the module level instead of compilation unit levelJan-Erik Rediger-0/+10
This was deleted here[1] which appears to be replaced by this[2] which is a new setPIELevel function on the LLVM module itself. [1]: http://reviews.llvm.org/D19753 [2]: http://reviews.llvm.org/D19671
2016-07-29[LLVM-3.9] Update return type for Archive::createJan-Erik Rediger-0/+8
Changed in https://github.com/rust-lang/llvm/commit/0b21d88fd31b4bfb6fdb7e2f1ed5f93639d5bd1c
2016-07-29[LLVM-3.9] Replace NewArchiveIterator with NewArchiveMemberJan-Erik Rediger-3/+17
The new NewArchiveMember is simpler and requires less context, according to upstream. This was changed in http://reviews.llvm.org/D21721
2016-07-29[LLVM-3.9] Preserve certain functions when internalizingJan-Erik Rediger-1/+16
This makes sure to still use the old way for older LLVM versions.
2016-07-29[LLVM-3.9] Specify that we are using the legacy interfaceJan-Erik Rediger-3/+3
LLVM pass manager infrastructure is currently getting rewritten to be more flexible, but the rewrite isn't complete yet.
2016-07-29[LLVM-3.9] Rename custom methods to Rust-specific onesJan-Erik Rediger-2/+2
2016-07-24Pass -DLLVM_RUSTLLVM to compile against rust llvm fork.Cameron Hart-3/+17
If using system llvm don't try use modifications made in the fork.
2016-07-11Add help for target CPUs, features, relocation and code models.Cameron Hart-0/+38
2016-07-08Update LLVM.Michael Woerister-1/+1
2016-06-09Remove unneeded indirection of GET_ARCHIVEJake Goulding-2/+1
2016-06-09Reflect supporting only LLVM 3.7+ in the LLVM wrappersJake Goulding-222/+4
2016-05-09rustc: Use C++ personalities on MSVCAlex Crichton-1/+1
Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust, meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions, meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of "personality function" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler`, but they both essentially are the "most generic" personality functions for catching exceptions and running cleanups. That is, thse two personalities will run cleanups for all exceptions unconditionally, so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to "C++ exception-like unwining"). Also note that the standard library only *catches* Rust exceptions, not others like segfaults and illegal instructions. LLVM has support for another personality, `__CxxFrameHandler3`, which does not run cleanups for general exceptions, only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case, so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet, but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself, but this... Closes #33112 Closes #33116
2016-04-26Update llvm to 751345228a0ef03fd147394bb5104359b7a808beFabrice Desré-1/+1
2016-04-09Implement feature extraction from `TargetMachine`Andrea Canciani-0/+69
Add the `LLVMRustHasFeature` function to check whether a `TargetMachine` has a given feature.
2016-03-29Use weak_odr linkage when reusing definitions across codegen unitsBjörn Steinbrink-0/+13
When reuing a definition across codegen units, we obviously cannot use internal linkage, but using external linkage means that we can end up with multiple conflicting definitions of a single symbol across multiple crates. Since the definitions should all be equal semantically, we can use weak_odr linkage to resolve the situation. Fixes #32518
2016-03-26Fix removal of function attributes on ARMBjörn Steinbrink-0/+10
We use a 64bit integer to pass the set of attributes that is to be removed, but the called C function expects a 32bit integer. On most platforms this doesn't cause any problems other than being unable to unset some attributes, but on ARM even the lower 32bit aren't handled correctly because the 64bit value is passed in different registers, so the C function actually sees random garbage. So we need to fix the relevant functions to use 32bit integers instead. Additionally we need an implementation that actually accepts 64bit integers because some attributes can only be unset that way. Fixes #32360
2016-03-19Auto merge of #32362 - bluss:float-fast-math, r=eddybbors-2/+4
Fix floating point fast-math intrinsics The implementation did not handle the case where both operands were constants, which caused an llvm assertion: ``` rustc: //buildslave//rust-buildbot//slave//nightly-dist-rustc-musl-linux//build//src//llvm//include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::Instruction; Y = llvm::Value; typename llvm::cast_retty<X, Y*>::ret_type = llvm::Instruction*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. ```
2016-03-19Fix LLVMRustSetHasUnsafeAlgebra to only have effect on instructionsUlrik Sverdrup-2/+4
2016-03-19Rollup merge of #32337 - dotdash:llvm-aa-perf, r=alexcrichtonEduard-Mihai Burtescu-1/+1
Update LLVM to include a backport to restore AA performance cc #31435 r? @alexcrichton
2016-03-18Add intrinsics for float arithmetic with `fast` flag enabledUlrik Sverdrup-0/+5
`fast` a.k.a UnsafeAlgebra is the flag for enabling all "unsafe" (according to llvm) float optimizations. See LangRef for more information http://llvm.org/docs/LangRef.html#fast-math-flags Providing these operations with less precise associativity rules (for example) is useful to numerical applications. For example, the summation loop: let sum = 0.; for element in data { sum += *element; } Using the default floating point semantics, this loop expresses the floats must be added in a sequence, one after another. This constraint is usually completely unintended, and it means that no autovectorization is possible.
2016-03-18Update LLVM to include a backport to restore AA performanceBjörn Steinbrink-1/+1
cc #31435
2016-03-15rustbuild: Fix LLVM compile on MinGWAlex Crichton-1/+1
The LLVM change [1] in #32239 unfortunately broke the LLVM build on MinGW, so this LLVM submodule update brings in one more fix [2] which should hopefully remedy that. Once this lands we should be able to immediately start gating on this to prevent it from happening again. [1]: https://github.com/rust-lang/llvm/commit/be89e4b5 [2]: https://github.com/rust-lang/llvm/commit/3dcd2c84
2016-03-14rustbuild: Fix cross compiling to FreeBSDAlex Crichton-1/+1
This commit fixes our support for cross compiling a compiler to run on FreeBSD. Over the weekend I managed to get a cross compiler from Linux to FreeBSD [1] which I hope to soon use to start producing FreeBSD nightly compilers. With the `make dist` support added in #32237 we should be able to produce standard rustc/rust-std packages for FreeBSD through a new slave with this cross compiler. Currently, however, we don't "Just Work" when cross compiling FreeBSD and a number of changes were required (part of this PR). They include: * A few build fixes were needed in LLVM. Our own branch has been rebased on the actual 3.8 release and I applied one extra commit [2] which contains two fixes: 1. The LLVM CMake build system passes the `-Wl,-z,defs` flag on many platforms, but *not* when `CMAKE_SYSTEM_NAME` is "FreeBSD". Unfortunately this doesn't take into account when we're cross compiling, and as predicted the build will fail if `-Wl,-z,defs` is passed (see [3] for more info). To fix this we test `TARGET_TRIPLE` instead of the `CMAKE_SYSTEM_NAME` which is what we're compiling for which fixes the problem. 2. The `PATH_MAX` constant is apparently defined in a different location than many other Unix systems, so a file which required this just needed some help to keep compiling. * Support for compiling compiler-rt with CMake has been added to rustbuild. It looks like it just emulates Linux in what it compiles as it didn't seem to naturally produce anything else... At least the architecture is right, so seems good for now at least! [1]: https://github.com/alexcrichton/port-of-rust/blob/master/prebuilt/freebsd/Dockerfile [2]: https://github.com/rust-lang/llvm/commit/be89e4b5 [3]: https://bugs.webkit.org/show_bug.cgi?id=138420
2016-02-24Implement filling drop in MIRSimonas Kazlauskas-0/+5
Hopefully the author caught all the cases. For the mir_dynamic_drops_3 test case the ratio of memsets to other instructions is 12%. On the other hand we actually do not double drop for at least the test cases provided anymore in MIR.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-05 20:28:48 +0000