summary refs log tree commit diff
path: root/src/rustllvm
AgeCommit message (Collapse)AuthorLines
2018-03-27Enable target_feature on any LLVM 6+Josh Stone-8/+4
In `LLVMRustHasFeature()`, rather than using `MCInfo->getFeatureTable()` that is specific to Rust's LLVM fork, we can use this in LLVM 6: /// Check whether the subtarget features are enabled/disabled as per /// the provided string, ignoring all other features. bool checkFeatures(StringRef FS) const; Now rustc using external LLVM can also have `target_feature`.
2018-03-27Auto merge of #49249 - gnzlbg:simd_minmax, r=alexcrichtonbors-0/+20
implement minmax intrinsics This adds the `simd_{fmin,fmax}` intrinsics, which do a vertical (lane-wise) `min`/`max` for floating point vectors that's equivalent to Rust's `min`/`max` for `f32`/`f64`. It might make sense to make `{f32,f64}::{min,max}` use the `minnum` and `minmax` intrinsics as well. --- ~~HELP: I need some help with these. Either I should go to sleep or there must be something that I must be missing. AFAICT I am calling the `maxnum` builder correctly, yet rustc/LLVM seem to insert a call to `llvm.minnum` there instead...~~ EDIT: Rust's LLVM version is too old :/
2018-03-26Auto merge of #48346 - emilio:pgo, r=alexcrichtonbors-1/+32
Add basic PGO support. This PR adds two mutually exclusive options for profile usage and generation using LLVM's instruction profile generation (the same as clang uses), `-C pgo-use` and `-C pgo-gen`. See each commit for details.
2018-03-26require llvm 6gnzlbg-0/+11
2018-03-26implement minmax intrinsicsgnzlbg-0/+9
2018-03-24Polyfill LLVMBuildExactUDivScott McMurray-0/+8
It was added 32 days after LLVM 3.9 shipped.
2018-03-25try to fix the build on older LLVM versions.Emilio Cobos Álvarez-0/+18
2018-03-25librustc_llvm: Show PGO diagnostics properly.Emilio Cobos Álvarez-0/+3
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
2018-03-25rustc_llvm: rustc_trans: Thread the PGO config down to the pass manager builder.Emilio Cobos Álvarez-1/+11
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
2018-03-15error via bug! instead of stderr+terminategnzlbg-39/+22
2018-03-15error on vector reduction usage if LLVM version is < 5.0gnzlbg-1/+20
2018-03-14add dummy symbols for LLVM<6gnzlbg-0/+47
2018-03-14expose ordered/unordered/nanless intirnsicsgnzlbg-0/+2
2018-03-13add intrinsics for portable packed simd vector reductionsgnzlbg-0/+46
2018-03-10Merge LLVM fix for undefined bss globalsvarkor-1/+1
This fixes #41315.
2018-03-06rustc: Update LLVMAlex Crichton-1/+1
This pulls in the rest of LLVM's `release_60` branch (the actual 6.0.0 release) and also pulls in a cherry-pick to... Closes #48226
2018-02-12rustc: Persist LLVM's `Linker` in Fat LTOAlex Crichton-40/+72
This commit updates our Fat LTO logic to tweak our custom wrapper around LLVM's "link modules" functionality. Previously whenever the `LLVMRustLinkInExternalBitcode` function was called it would call LLVM's `Linker::linkModules` wrapper. Internally this would crate an instance of a `Linker` which internally creates an instance of an `IRMover`. Unfortunately for us the creation of `IRMover` is somewhat O(n) with the input module. This means that every time we linked a module it was O(n) with respect to the entire module we had built up! Now the modules we build up during LTO are quite large, so this quickly started creating an O(n^2) problem for us! Discovered in #48025 it turns out this has always been a problem and we just haven't noticed it. It became particularly worse recently though due to most libraries having 16x more object files than they previously did (1 -> 16). This commit fixes this performance issue by preserving the `Linker` instance across all links into the main LLVM module. This means we only create one `IRMover` and allows LTO to progress much speedier. From the `cargo-cache` project in #48025 a **full build** locally when from 5m15s to 2m24s. Looking at the timing logs each object file was linked in in single-digit millisecond rather than hundreds, clearly being a nice improvement! Closes #48025
2018-02-09rustc: Upgrade to LLVM 6Alex Crichton-1/+3
The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening, but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed, notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch, but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container, I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch), but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies, but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome, along with scrutiny of the "missing patches" like a [change to pass manager order](rust-lang/llvm@27174447533), [another change to pass manager order](rust-lang/llvm@c782febb7b9), some [compile fixes for sparc](rust-lang/llvm@1a83de63c42), and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1 [backport]: https://github.com/rust-lang/llvm/commit/5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons, notably: * This'll allow us to keep up with the upstream wasm backend, picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors, especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend, but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction, but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang-nursery/stdsimd#157 Closes rust-lang-nursery/rust-wasm#3
2018-01-30rustc: Add some defines for LLVM 7 compatAlex Crichton-0/+11
I was testing out the tip support to see what's going on with wasm, and this was I believe the only issue encountered with LLVM 7 support so far.
2018-01-26Merge branch 'mlsm' of https://github.com/dotdash/rust into rollupAlex Crichton-1/+1
2018-01-26Upgrade LLVM to incorporate a fix for #47364Björn Steinbrink-1/+1
Fixes #47364
2018-01-25Rollup merge of #47710 - alexcrichton:llvm-6-compat, r=nikomatsakisAlex Crichton-14/+29
First round of LLVM 6.0.0 compatibility This includes a number of commits for the first round of upgrading to LLVM 6. There are still [lingering bugs](https://github.com/rust-lang/rust/issues/47683) but I believe all of this will nonetheless be necessary!
2018-01-25Rollup merge of #47618 - mrhota:dw_at_noreturn, r=michaelwoeristerAlex Crichton-2/+18
Teach rustc about DW_AT_noreturn and a few more DIFlags We achieve two small things with this PR: 1. We provide definitions for a few additional llvm debuginfo flags 1. We _use_ one of these new flags, `FlagNoReturn`, and add it to debuginfo for functions with the never return type (`!`).
2018-01-24llvm6: Different return value for writeArchiveAlex Crichton-3/+10
Updated in llvm-mirror/llvm@203c90ba this function now just returns an `Error`, so this updates the C++ bindings accordingly
2018-01-24llvm6: Remove MIPS64 archive variantAlex Crichton-3/+0
It looks like LLVM also removed it in llvm-mirror/llvm@f45adc29d in favor of the name "GNU64". This was added in the thought that we'd need such a variant when adding mips64 support but we ended up not needing it! For now let's just removing the various support on the Rust side of things.
2018-01-24llvm6: Tweak fast math intrinsicsAlex Crichton-0/+4
Looks like they did some refactoring of flags in the backend and this should catch us up! The "unsafe algebra" boolean has been split into a number of boolean flags for various operations, and this updates to use the `setFast` function which should hopefully have the same behavior as before. This was updated in llvm-mirror/llvm@00e900afd
2018-01-24llvm6: Missing include for LLVM 6 in PassWrapper.cppAlex Crichton-0/+1
Just bog-standard compile error fixed by adding some new header files
2018-01-24llvm6: CodeModel::{JIT,}Default no longer existsAlex Crichton-8/+14
LLVM has since removed the `CodeModel::Default` enum value in favor of an `Optional` implementationg throughout LLVM. Let's mirror the same change in Rust and update the various bindings we call accordingly. Removed in llvm-mirror/llvm@9aafb854c
2018-01-21Ensure test doesn't run with llvm 3.9A.J. Gardner-1/+1
2018-01-20Teach rustc about DW_AT_noreturn and a few more DIFlagsA.J. Gardner-2/+18
2018-01-19Update DW_OP_plus to DW_OP_plus_uconstJosh Stone-1/+8
LLVM <= 4.0 used a non-standard interpretation of `DW_OP_plus`. In the DWARF standard, this adds two items on the expressions stack. LLVM's behavior was more like DWARF's `DW_OP_plus_uconst` -- adding a constant that follows the op. The patch series starting with [D33892] switched to the standard DWARF interpretation, so we need to follow. [D33892]: https://reviews.llvm.org/D33892
2018-01-14rustc_trans: remove unused `TargetDataRef` accessor.Eduard-Mihai Burtescu-4/+0
2018-01-07Remove unused LLVMRustJITMemoryManagerRef typedefBjörn Steinbrink-1/+0
2018-01-07Remove dead function rustc_llvm::debug_loc_to_string()Björn Steinbrink-9/+0
Refs #46437 as it also removes LLVMRustWriteDebugLocToString()
2018-01-07Remove dead function LLVMRustLinkInParsedExternalBitcode()Björn Steinbrink-17/+0
Refs #46437
2018-01-07Remove redundant -Zdebug-llvm optionBjörn Steinbrink-6/+0
The same effect can be achieved using -Cllvm-args=-debug Refs #46437 as it removes LLVMRustSetDebug()
2018-01-07Rollup merge of #47220 - nagisa:nonamellvm, r=rkruppekennytm-2/+8
Use name-discarding LLVM context This is only applicable when neither of --emit=llvm-ir or --emit=llvm-bc are not requested. In case either of these outputs are wanted, but the benefits of such context are desired as well, -Zfewer_names option provides the same functionality regardless of the outputs requested. Should be a viable fix for https://github.com/rust-lang/rust/issues/46449
2018-01-06Rollup merge of #47173 - dotdash:cleanup, r=michaelwoeristerGuillaume Gomez-18/+2
Remove some outdated LLVM-related code Ticks two boxes on #46437
2018-01-05Use name-discarding LLVM contextSimonas Kazlauskas-2/+8
This is only applicable when neither of --emit=llvm-ir or --emit=llvm-bc are not requested. In case either of these outputs are wanted, but the benefits of such context are desired as well, -Zfewer_names option provides the same functionality regardless of the outputs requested.
2018-01-05Auto merge of #46739 - arielb1:simple-loops, r=nikomatsakisbors-1/+1
[needs perf run] Try to improve LLVM pass ordering Fixes #45466
2018-01-04Simplify LLVMRustModuleCost()Björn Steinbrink-7/+2
2018-01-04Remove unused function LLVMRustGetValueContext()Björn Steinbrink-4/+0
Refs #46437
2018-01-04Remove outdated LLVMRustBuildLandingPad() wrapperBjörn Steinbrink-7/+0
The function was added as a wrapper to handle compatibility with older LLVM versions that we no longer support, so it can be removed. Refs #46437
2017-12-23rustc: Set release mode cgus to 16 by defaultAlex Crichton-0/+15
This commit is the next attempt to enable multiple codegen units by default in release mode, getting some of those sweet, sweet parallelism wins by running codegen in parallel. Performance should not be lost due to ThinLTO being on by default as well. Closes #45320
2017-12-18rustc: Work around `DICompileUnit` bugs in LLVMAlex Crichton-0/+80
This commit implements a workaround for #46346 which basically just avoids triggering the situation that LLVM's bug https://bugs.llvm.org/show_bug.cgi?id=35562 arises. More details can be found in the code itself but this commit is also intended to ... Closes #46346
2017-12-15Rollup merge of #46652 - ishitatsuyuki:thinlto-backport, r=alexcrichtonSteve Klabnik-0/+8
ThinLTO: updates for LLVM 5 refs: https://github.com/llvm-mirror/llvm/commit/ccb80b9c0f60f33780e5e29bf66a87bb56968b99 https://github.com/llvm-mirror/llvm/commit/e611018a3f1237c9328763027db4a616ed7be04a
2017-12-14Simplify CFG after IndVarSimplifyAriel Ben-Yehuda-1/+1
Fixes #45466
2017-12-12Fix return value of `LLVMRustMetadataAsValue`varkor-2/+2
`LLVMRustMetadataAsValue` would previously return `void`, despite the corresponding Rust function expecting to return a `ValueRef`.
2017-12-12ThinLTO: updates for LLVM 5Tatsuyuki Ishi-0/+8
refs: https://github.com/llvm-mirror/llvm/commit/ccb80b9c0f60f33780e5e29bf66a87bb56968b99 https://github.com/llvm-mirror/llvm/commit/e611018a3f1237c9328763027db4a616ed7be04a
2017-12-07rustc: Further tweak linkage in ThinLTOAlex Crichton-1/+1
In #46382 the logic around linkage preservation with ThinLTO ws tweaked but the loop that registered all otherwise exported GUID values as "don't internalize me please" was erroneously too conservative and only asking "external" linkage items to not be internalized. Instead we actually want the inversion of that condition, everything *without* "local" linkage to be internalized. This commit updates the condition there, adds a test, and... Closes #46543
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 22:55:57 +0000