about summary refs log tree commit diff
path: root/src/rustllvm
AgeCommit message (Collapse)AuthorLines
2018-08-02Auto merge of #52787 - riscv-rust:riscv-rust-pr, r=alexcrichtonbors-1/+8
Enable RISCV - Enable LLVM backend. - Implement call abi. - Add built-in target riscv32imac-unknown-none. - Enable CI.
2018-08-01[RISCV] Enable LLVM backend.David Craven-1/+8
2018-08-01Auto merge of #52474 - alexcrichton:better-lto-error, r=eddybbors-0/+3
rustc: Handle linker diagnostics from LLVM Previously linker diagnostic were being hidden when two modules were linked together but failed to link. This commit fixes the situation by ensuring that we have a diagnostic handler installed and also adds support for handling linker diagnostics.
2018-08-01Rollup merge of #52824 - varkor:fix-llvm-ret-move-warnings, r=rkruppePietro Albini-3/+3
Fix -Wpessimizing-move warnings in rustllvm/PassWrapper These are producing warnings when building rustc (`warning: moving a local object in a return statement prevents copy elision [-Wpessimizing-move]`).
2018-07-31rustc: Handle linker diagnostic from LLVMAlex Crichton-0/+3
Previously linker diagnostic were being hidden when two modules were linked together but failed to link. This commit fixes the situation by ensuring that we have a diagnostic handler installed and also adds support for handling linker diagnostics.
2018-07-30rustc_codegen_llvm: remove more unused functions.Irina Popa-33/+0
2018-07-30rustc_llvm: move to rustc_codegen_llvm::llvm.Irina Popa-1/+1
2018-07-29Fix -Wpessimizing-move warnings in rustllvm/PassWrappervarkor-3/+3
2018-07-23Auto merge of #52506 - alexcrichton:dont-duplicate-wasm-sections, ↵bors-1/+30
r=michaelwoerister rustc: Work around an upstream wasm ThinLTO bug This commit implements a workaround for an [upstream LLVM bug][1] where custom sections were accidentally duplicated amongst codegen units when ThinLTO passes were performed. This is due to the fact that custom sections for wasm are stored as metadata nodes which are automatically imported into modules when ThinLTO happens. The fix here is to forcibly delete the metadata node from imported modules before LLVM has a chance to try to copy it over. [1]: https://bugs.llvm.org/show_bug.cgi?id=38184
2018-07-18rustc: Work around an upstream wasm ThinLTO bugAlex Crichton-1/+30
This commit implements a workaround for an [upstream LLVM bug][1] where custom sections were accidentally duplicated amongst codegen units when ThinLTO passes were performed. This is due to the fact that custom sections for wasm are stored as metadata nodes which are automatically imported into modules when ThinLTO happens. The fix here is to forcibly delete the metadata node from imported modules before LLVM has a chance to try to copy it over. [1]: https://bugs.llvm.org/show_bug.cgi?id=38184
2018-07-18rustc: Remove a workaroudn in ThinLTO fixed upstreamAlex Crichton-14/+0
This commit removes a hack in our ThinLTO passes which removes available externally functions manually. The [upstream bug][1] has long since been fixed, so we should be able to rely on LLVM natively for this now! [1]: https://bugs.llvm.org/show_bug.cgi?id=35736
2018-07-16Revert "Provide a way of accessing the ThinLTO module import map in rustc."Michael Woerister-56/+0
This reverts commit 9df56ca0eea1a8f5af945df25ce23e276b1d48a7.
2018-07-16Revert "Use callback-based interface to load ThinLTO import data into rustc."Michael Woerister-20/+47
This reverts commit e045a6cd8c0235a26ef11e6cd9a13ebd817f1265.
2018-07-13Auto merge of #52266 - michaelwoerister:incr-thinlto-preliminaries, ↵bors-0/+29
r=alexcrichton Preliminary work for incremental ThinLTO. Since implementing incremental ThinLTO is a bit more involved than I initially thought, I'm splitting out some of the things that already work. This PR (1) adds a way accessing some ThinLTO information in `rustc` and (2) does some cleanup around CGU/object file naming (which makes things quite a bit nicer). This is probably best reviewed one commit at a time.
2018-07-13Use callback-based interface to load ThinLTO import data into rustc.Michael Woerister-47/+20
2018-07-12Update llvm-rebuild-trigger in light of LLVM 7 upgradevarkor-1/+1
2018-07-11Provide a way of accessing the ThinLTO module import map in rustc.Michael Woerister-0/+56
2018-07-11Auto merge of #51966 - alexcrichton:llvm7, r=michaelwoeristerbors-0/+4
Upgrade to LLVM's master branch (LLVM 7) ### Current status ~~Blocked on a [performance regression](https://github.com/rust-lang/rust/pull/51966#issuecomment-402320576). The performance regression has an [upstream LLVM issue](https://bugs.llvm.org/show_bug.cgi?id=38047) and has also [been bisected](https://reviews.llvm.org/D44282) to an LLVM revision.~~ Ready to merge! --- This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * ~~The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug]~~ Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382 cc #50543
2018-07-10Upgrade to LLVM's master branch (LLVM 7)Alex Crichton-0/+4
This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382
2018-07-09still support LLVM4 for emscriptengnzlbg-1/+167
2018-07-09bump minimum LLVM version to 5.0gnzlbg-198/+3
2018-07-07removed redundant header file import in rustllvm.hPramod Bisht-2/+0
2018-05-20Rollup merge of #50827 - nox:llvmup, r=eddybkennytm-1/+1
Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97 This brings in https://github.com/rust-lang/llvm/pull/115, which fixes https://github.com/rust-lang/rust/issues/49873.
2018-05-18Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97Anthony Ramine-1/+1
This brings in https://github.com/rust-lang/llvm/pull/115, which fixes https://github.com/rust-lang/rust/issues/49873.
2018-05-17Rename trans to codegen everywhere.Irina Popa-1/+1
2018-05-15Reenable the MergeFunctions passAnthony Ramine-2/+3
The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc pass enabled and it hugely reduces code size (for example it shaves off 10% of the final Servo executable). This patch reenables it.
2018-05-12Set PrepareForThinLTO flag when using ThinLTONikita Popov-1/+4
The LLVM PassManager has a PrepareForThinLTO flag, which is intended when compilation occurs in conjunction with linking by ThinLTO. The flag has two effects: * The NameAnonGlobal pass is run after all other passes, which ensures that all globals have a name. * In optimized builds, a number of late passes (mainly related to vectorization and unrolling) are disabled, on the rationale that these a) will increase codesize of the intermediate artifacts and b) will be run by ThinLTO again anyway. This patch enables the use of PrepareForThinLTO if Thin or ThinLocal linking is used. The background for this change is the CI failure in #49479, which we assume to be caused by the NameAnonGlobal pass not being run. As this changes which passes LLVM runs, this might have performance (or other) impact, so we want to land this separately.
2018-04-12Use the GlobalAlloc trait for #[global_allocator]Simon Sapin-1/+1
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!
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 23:37:38 +0000