summaryrefslogtreecommitdiff
path: root/compiler/rustc_llvm/llvm-wrapper
Commit message (Collapse)AuthorAgeFilesLines
...
* | Stub out more PassManagerBuilder functionsNikita Popov2022-04-201-1/+52
| |
* | Stub out various legacy PM functions with LLVM 15Nikita Popov2022-04-201-0/+44
| |
* | Add missing includeNikita Popov2022-04-201-0/+1
| |
* | Add codegen for global_asm! sym operandsAmanieu d'Antras2022-04-151-0/+6
| |
* | Respect -Z verify-llvm-ir and other flags that add extra passes when ↵Luqman Aden2022-04-101-0/+7
|/ | | | combined with -C no-prepopulate-passes in the new LLVM Pass Manager.
* RustWrapper: add missing includeAugie Fackler2022-03-101-0/+1
| | | | | This is required after LLVM change 3c4410dfcaaf (aka https://reviews.llvm.org/D121168) did some includes cleanup.
* Pass LLVM string attributes as string slicesTomasz Miąsko2022-03-031-6/+0
|
* Auto merge of #94229 - erikdesjardins:rem2, r=nikicbors2022-03-021-26/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove LLVM attribute removal This was necessary before, because `declare_raw_fn` would always apply the default optimization attributes to every declared function. Then `attributes::from_fn_attrs` would have to remove the default attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build. (see [`src/test/codegen/optimize-attr-1.rs`](https://github.com/rust-lang/rust/blob/03a8cc7df1d65554a4d40825b0490c93ac0f0236/src/test/codegen/optimize-attr-1.rs#L33)) However, every relevant callsite of `declare_raw_fn` (i.e. where we actually generate code for the function, and not e.g. a call to an intrinsic, where optimization attributes don't [?] matter) calls `from_fn_attrs`, so we can remove the attribute setting from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct attributes all at once. r? `@ghost` (blocked on #94221) `@rustbot` label S-blocked
| * Remove LLVM attribute removalErik Desjardins2022-02-281-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This was necessary before, because `declare_raw_fn` would always apply the default optimization attributes to every declared function, and then `attributes::from_fn_attrs` would have to remove the default attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build. However, every relevant callsite of `declare_raw_fn` (i.e. where we actually generate code for the function, and not e.g. a call to an intrinsic, where optimization attributes don't [?] matter) calls `from_fn_attrs`, so we can simply remove the attribute setting from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct attributes all at once.
* | Revert "Auto merge of #92419 - erikdesjardins:coldland, r=nagisa"Erik Desjardins2022-02-271-8/+0
|/ | | | | This reverts commit 4f49627c6fe2a32d1fed6310466bb0e1c535c0c0, reversing changes made to 028c6f1454787c068ff5117e9000a1de4fd98374.
* AttrBuilder doesn't take a context in old LLVMErik Desjardins2022-02-261-4/+7
|
* use attrbuilder to remove attrs in old LLVMErik Desjardins2022-02-261-4/+7
|
* Add LLVM attributes in batches instead of individuallyErik Desjardins2022-02-261-105/+60
| | | | This should improve performance.
* Rollup merge of #91675 - ivanloz:memtagsan, r=nagisaMatthias Krüger2022-02-182-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add MemTagSanitizer Support Add support for the LLVM [MemTagSanitizer](https://llvm.org/docs/MemTagSanitizer.html). On hardware which supports it (see caveats below), the MemTagSanitizer can catch bugs similar to AddressSanitizer and HardwareAddressSanitizer, but with lower overhead. On a tag mismatch, a SIGSEGV is signaled with code SEGV_MTESERR / SEGV_MTEAERR. # Usage `-Zsanitizer=memtag -C target-feature="+mte"` # Comments/Caveats * MemTagSanitizer is only supported on AArch64 targets with hardware support * Requires `-C target-feature="+mte"` * LLVM MemTagSanitizer currently only performs stack tagging. # TODO * Tests * Example
| * MemTagSanitizer SupportIvan Lozano2022-02-162-0/+3
| | | | | | | | Adds support for the LLVM MemTagSanitizer.
* | llvm: migrate to new parameter-bearing uwtable attrAugie Fackler2022-02-141-0/+11
|/ | | | | | | | | | | | In https://reviews.llvm.org/D114543 the uwtable attribute gained a flag so that we can ask for sync uwtables instead of async, as the former are much cheaper. The default is async, so that's what I've done here, but I left a TODO that we might be able to do better. While in here I went ahead and dropped support for removing uwtable attributes in rustc: we never did it, so I didn't write the extra C++ bridge code to make it work. Maybe I should have done the same thing with the `sync|async` parameter but we'll see.
* Apply noundef attribute to &T, &mut T, Box<T>, boolErik Desjardins2022-02-052-0/+3
| | | | | | | | | This doesn't handle `char` because it's a bit awkward to distinguish it from u32 at this point in codegen. Note that for some types (like `&Struct` and `&mut Struct`), we already apply `dereferenceable`, which implies `noundef`, so the IR does not change.
* Windows: Disable LLVM crash dialog boxes.Eric Huss2022-01-271-0/+4
|
* Use error-on-mismatch policy for PAuth module flags.Jacob Bramley2022-01-241-3/+6
| | | | | | | | | This agrees with Clang, and avoids an error when using LTO with mixed C/Rust. LLVM considers different behaviour flags to be a mismatch, even when the flag value itself is the same. This also makes the flag setting explicit for all uses of LLVMRustAddModuleFlag.
* Remove LLVMRustMarkAllFunctionsNounwindAmanieu d'Antras2022-01-141-19/+0
| | | | | | | | | | | This was originally introduced in #10916 as a way to remove all landing pads when performing LTO. However this is no longer necessary today since rustc properly marks all functions and call-sites as nounwind where appropriate. In fact this is incorrect in the presence of `extern "C-unwind"` which must create a landing pad when compiled with `-C panic=abort` so that foreign exceptions are caught and properly turned into aborts.
* Rollup merge of #92559 - durin42:llvm-14-attributemask, r=nikicMatthias Krüger2022-01-061-5/+3
|\ | | | | | | | | | | | | | | | | RustWrapper: adapt to new AttributeMask API Upstream LLVM change 9290ccc3c1a1 migrated attribute removal to use AttributeMask instead of AttrBuilder, so we need to follow suit here. r? ``@nagisa`` cc ``@nikic``
| * RustWrapper: simplify removing attributesAugie Fackler2022-01-051-7/+3
| | | | | | | | Avoids some extra conversions. Spotted by nikic during review.
| * RustWrapper: adapt to new AttributeMask APIAugie Fackler2022-01-041-2/+4
| | | | | | | | | | Upstream LLVM change 9290ccc3c1a1 migrated attribute removal to use AttributeMask instead of AttrBuilder, so we need to follow suit here.
* | RustWrapper: adapt for an LLVM API changeKrasimir Georgiev2022-01-031-4/+4
|/ | | | | | | | | No functional changes intended. The LLVM commit https://github.com/llvm/llvm-project/commit/ec501f15a8b8ace2b283732740d6d65d40d82e09 removed the signed version of `createExpression`. This adapts the Rust LLVM wrappers accordingly.
* Auto merge of #92419 - erikdesjardins:coldland, r=nagisabors2022-01-011-0/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | Mark drop calls in landing pads `cold` instead of `noinline` Now that deferred inlining has been disabled in LLVM (#92110), this shouldn't cause catastrophic size blowup. I confirmed that the test cases from https://github.com/rust-lang/rust/issues/41696#issuecomment-298696944 still compile quickly (<1s) after this change. ~Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled, so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.~ (edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder, because I forgot to make it conditional on LLVM version) r? `@nagisa` cc `@arielb1` (this effectively reverts #42771 "mark calls in the unwind path as !noinline") cc `@RalfJung` (fixes #46515) edit: also fixes #87055
| * keep noinline for system llvm < 14Erik Desjardins2021-12-301-0/+8
| |
* | Use the existing llvm-plugins option for both legacy and new pm registrationAxel Cohen2021-12-131-4/+4
| |
* | Add a codegen option to allow loading LLVM pass pluginsAxel Cohen2021-12-131-1/+17
|/
* LLVM codgen support for unwinding inline assemblycynecx2021-12-031-0/+8
|
* Adjust llvm wrapper for unwinding support for inlineasmcynecx2021-12-031-2/+3
|
* Rollup merge of #91207 - richkadel:rk-bump-coverage-version, r=tmandryMatthias Krüger2021-12-011-2/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for LLVM coverage mapping format versions 5 and 6 This PR cherry-pick's Swatinem's initial commit in unsubmitted PR #90047. My additional commit augments Swatinem's great starting point, but adds full support for LLVM Coverage Mapping Format version 6, conditionally, if compiling with LLVM 13. Version 6 requires adding the compilation directory when file paths are relative, and since Rustc coverage maps use relative paths, we should add the expected compilation directory entry. Note, however, that with the compilation directory, coverage reports from `llvm-cov show` can now report file names (when the report includes more than one file) with the full absolute path to the file. This would be a problem for test results, but the workaround (for the rust coverage tests) is to include an additional `llvm-cov show` parameter: `--compilation-dir=.`
| * Update CoverageMappingFormat Support to Version6Arpad Borsos2021-11-231-2/+7
| | | | | | | | | | Version 5 adds Branch Regions which are a prerequisite for branch coverage. Version 6 can use the zeroth filename as prefix for other relative files.
* | Rollup merge of #90833 - tmiasko:optimization-remarks, r=nikicMatthias Krüger2021-11-281-0/+93
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Emit LLVM optimization remarks when enabled with `-Cremark` The default diagnostic handler considers all remarks to be disabled by default unless configured otherwise through LLVM internal flags: `-pass-remarks`, `-pass-remarks-missed`, and `-pass-remarks-analysis`. This behaviour makes `-Cremark` ineffective on its own. Fix this by configuring a custom diagnostic handler that enables optimization remarks based on the value of `-Cremark` option. With `-Cremark=all` enabling all remarks. Fixes #90924. r? `@nikic`
| * Recognize machine optimization remarksTomasz Miąsko2021-11-161-0/+3
| |
| * Emit LLVM optimization remarks when enabled with `-Cremark`Tomasz Miąsko2021-11-161-0/+90
| | | | | | | | | | | | | | | | | | | | | | The default diagnostic handler considers all remarks to be disabled by default unless configured otherwise through LLVM internal flags: `-pass-remarks`, `-pass-remarks-missed`, and `-pass-remarks-analysis`. This behaviour makes `-Cremark` ineffective on its own. Fix this by configuring a custom diagnostic handler that enables optimization remarks based on the value of `-Cremark` option. With `-Cremark=all` enabling all remarks.
* | add rustc option for using LLVM stack smash protectionBenjamin A. Bjørnseth2021-11-222-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLVM has built-in heuristics for adding stack canaries to functions. These heuristics can be selected with LLVM function attributes. This patch adds a rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use of these attributes. This gives rustc the same stack smash protection support as clang offers through options `-fno-stack-protector`, `-fstack-protector`, `-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html), originally discussed in #15179. Stack smash protection adds runtime overhead and is therefore still off by default, but now users have the option to trade performance for security as they see fit. An example use case is adding Rust code in an existing C/C++ code base compiled with stack smash protection. Without the ability to add stack smash protection to the Rust code, the code base artifacts could be exploitable in ways not possible if the code base remained pure C/C++. Stack smash protection support is present in LLVM for almost all the current tier 1/tier 2 targets: see test/assembly/stack-protector/stack-protector-target-support.rs. The one exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a warning message printed if stack smash protection is used with this target (see test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3 targets has not been checked. Since the heuristics are applied at the LLVM level, the heuristics are expected to add stack smash protection to a fraction of functions comparable to C/C++. Some experiments demonstrating how Rust code is affected by the different heuristics can be found in test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is potential for better heuristics using Rust-specific safety information. For example it might be reasonable to skip stack smash protection in functions which transitively only use safe Rust code, or which uses only a subset of functions the user declares safe (such as anything under `std.*`). Such alternative heuristics could be added at a later point. LLVM also offers a "safestack" sanitizer as an alternative way to guard against stack smashing (see #26612). This could possibly also be included as a stack-protection heuristic. An alternative is to add it as a sanitizer (#39699). This is what clang does: safestack is exposed with option `-fsanitize=safe-stack`. The options are only supported by the LLVM backend, but as with other codegen options it is visible in the main codegen option help menu. The heuristic names "basic", "strong", and "all" are hopefully sufficiently generic to be usable in other backends as well. Reviewed-by: Nikita Popov <nikic@php.net> Extra commits during review: - [address-review] make the stack-protector option unstable - [address-review] reduce detail level of stack-protector option help text - [address-review] correct grammar in comment - [address-review] use compiler flag to avoid merging functions in test - [address-review] specify min LLVM version in fortanix stack-protector test Only for Fortanix test, since this target specifically requests the `--x86-experimental-lvi-inline-asm-hardening` flag. - [address-review] specify required LLVM components in stack-protector tests - move stack protector option enum closer to other similar option enums - rustc_interface/tests: sort debug option list in tracking hash test - add an explicit `none` stack-protector option Revert "set LLVM requirements for all stack protector support test revisions" This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
* | Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`Josh Stone2021-11-191-1/+11
|/ | | | | | | | | | | | | `Module::getOrInsertGlobal` returns a `Constant*`, which is a super class of `GlobalVariable`, but if the given type doesn't match an existing declaration, it returns a bitcast of that global instead. This causes UB when we pass that to `LLVMGetVisibility` which unconditionally casts the opaque argument to a `GlobalValue*`. Instead, we can do our own get-or-insert without worrying whether existing types match exactly. It's not relevant when we're just trying to get/set the linkage and visibility, and if types are needed we can bitcast or error nicely from `rustc_codegen_llvm` instead.
* PassWrapper: additional sanitizer update to match clangKrasimir Georgiev2021-11-111-1/+0
| | | | | | This happened later in the stream than the other changes, but the fix is overlapping. Fix taken from a55c4ec1cee7683d9095327d9d33e7137ec25292 in LLVM.
* Didn't mean to invert this boolean.Augie Fackler2021-11-091-1/+1
|
* rustc_llvm: update PassWrapper for recent LLVMAugie Fackler2021-11-091-6/+9
| | | | | | | Now AddressSanitizerOptions is a struct, but at least the change was tiny. r? nikic
* Initialize LLVM time trace profiler on each code generation threadTomasz Miąsko2021-11-051-0/+4
| | | | | | | | | | | | | | | | | | | In https://reviews.llvm.org/D71059 LLVM 11, the time trace profiler was extended to support multiple threads. `timeTraceProfilerInitialize` creates a thread local profiler instance. When a thread finishes `timeTraceProfilerFinishThread` moves a thread local instance into a global collection of instances. Finally when all codegen work is complete `timeTraceProfilerWrite` writes data from the current thread local instance and the instances in global collection of instances. Previously, the profiler was intialized on a single thread only. Since this thread performs no code generation on its own, the resulting profile was empty. Update LLVM codegen to initialize & finish time trace profiler on each code generation thread.
* Rollup merge of #89581 - jblazquez:master, r=Mark-SimulacrumMatthias Krüger2021-10-251-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add -Z no-unique-section-names to reduce ELF header bloat. This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions. By default, when enabling function sections (which is the default for most targets), the LLVM backend will generate different section names for each function. For example, a function `func` would generate a section called `.text.func`. Normally this is fine because the linker will merge all those sections into a single one in the binary. However, starting with [LLVM 12](https://github.com/llvm/llvm-project/commit/ee5d1a04), the backend will also generate unique section names for exception handling, resulting in thousands of `.gcc_except_table.*` sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion [here](https://reviews.llvm.org/D83655)). This can bloat the ELF headers and string table significantly in binaries that contain many functions. The new option is analogous to Clang's `-fno-unique-section-names`, and instructs LLVM to generate the same `.text` and `.gcc_except_table` section for each function, resulting in a smaller final binary. The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65,000) that it broke some existing ELF tools, which couldn't handle so many sections. Here's our old binary: ``` $ readelf --sections old.elf | head -1 There are 71746 section headers, starting at offset 0x2a246508: $ readelf --sections old.elf | grep shstrtab [71742] .shstrtab STRTAB 0000000000000000 2977204c ad44bb 00 0 0 1 ``` That's an 11MB+ string table. Here's the new binary using this option: ``` $ readelf --sections new.elf | head -1 There are 43 section headers, starting at offset 0x29143ca8: $ readelf --sections new.elf | grep shstrtab [40] .shstrtab STRTAB 0000000000000000 29143acc 0001db 00 0 0 1 ``` The whole binary size went down by over 20MB, which is quite significant.
| * Add -Z no-unique-section-names to reduce ELF header bloat.Javier Blazquez2021-10-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions. By default, when enabling function sections (which is the default for most targets), the LLVM backend will generate different section names for each function. For example, a function "func" would generate a section called ".text.func". Normally this is fine because the linker will merge all those sections into a single one in the binary. However, starting with LLVM 12 (llvm/llvm-project@ee5d1a0), the backend will also generate unique section names for exception handling, resulting in thousands of ".gcc_except_table.*" sections ending up in the final binary because some linkers don't currently merge or strip these EH sections. This can bloat the ELF headers and string table significantly in binaries that contain many functions. The new option is analogous to Clang's -fno-unique-section-names, and instructs LLVM to generate the same ".text" and ".gcc_except_table" section for each function, resulting in smaller object files and potentially a smaller final binary.
* | Update the minimum external LLVM to 12Josh Stone2021-10-222-98/+2
| |
* | Update the minimum external LLVM to 11Josh Stone2021-10-223-114/+0
| |
* | RustWrapper: adapt for an LLVM API changeKrasimir Georgiev2021-10-182-1/+5
| | | | | | | | | | | | | | | | | | No functional changes intended. The LLVM commit https://github.com/llvm/llvm-project/commit/89b57061f7b769e9ea9bf6ed686e284f3e55affe moved TargetRegistry.(h|cpp) from Support to MC. This adapts RustWrapper accordingly.
* | Rollup merge of #89025 - ricobbe:raw-dylib-link-ordinal, r=michaelwoeristerJubilee2021-10-071-4/+7
|\ \ | | | | | | | | | | | | | | | | | | | | | Implement `#[link_ordinal(n)]` Allows the use of `#[link_ordinal(n)]` with `#[link(kind = "raw-dylib")]`, allowing Rust to link against DLLs that export symbols by ordinal rather than by name. As long as the ordinal matches, the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL. Part of #58713.
| * | Implement #[link_ordinal] attribute in the context of #[link(kind = ↵Richard Cobbe2021-09-201-4/+7
| | | | | | | | | | | | "raw-dylib")].
* | | Rollup merge of #87918 - mikebenfield:pr-afdo, r=nikicJubilee2021-10-071-9/+21
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable AutoFDO. This largely involves implementing the options debug-info-for-profiling and profile-sample-use and forwarding them on to LLVM. AutoFDO can be used on x86-64 Linux like this: rustc -O -Clink-arg='Wl,--no-rosegment' -Cdebug-info-for-profiling main.rs -o main perf record -b ./main create_llvm_prof --binary=main --out=code.prof rustc -O -Cprofile-sample-use=code.prof main.rs -o main2 Now `main2` will have feedback directed optimization applied to it. The create_llvm_prof tool can be obtained from this github repository: https://github.com/google/autofdo The option -Clink-arg='Wl,--no-rosegment' is necessary to avoid lld putting an extra RO segment before the executable code, which would make the binary silently incompatible with create_llvm_prof.
| * | | Enable AutoFDO.Michael Benfield2021-10-061-9/+21
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This largely involves implementing the options debug-info-for-profiling and profile-sample-use and forwarding them on to LLVM. AutoFDO can be used on x86-64 Linux like this: rustc -O -Cdebug-info-for-profiling main.rs -o main perf record -b ./main create_llvm_prof --binary=main --out=code.prof rustc -O -Cprofile-sample-use=code.prof main.rs -o main2 Now `main2` will have feedback directed optimization applied to it. The create_llvm_prof tool can be obtained from this github repository: https://github.com/google/autofdo Fixes #64892.
View Lorry Controller Status