Commit Graph

113 Commits

Author SHA1 Message Date
Augie Fackler
185e3b95ca RustWrapper: add missing include
This is required after LLVM change 3c4410dfcaaf (aka
https://reviews.llvm.org/D121168) did some includes cleanup.
2022-03-10 11:16:33 -05:00
Tomasz Miąsko
926bf1a371 Pass LLVM string attributes as string slices 2022-03-03 00:28:50 +01:00
bors
c42d846add Auto merge of #94229 - erikdesjardins:rem2, r=nikic
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`](03a8cc7df1/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
2022-03-02 08:48:33 +00:00
Erik Desjardins
dce14cfacc Remove LLVM attribute removal
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.
2022-02-28 00:02:11 -05:00
Erik Desjardins
851fcc7a54 Revert "Auto merge of #92419 - erikdesjardins:coldland, r=nagisa"
This reverts commit 4f49627c6f, reversing
changes made to 028c6f1454.
2022-02-27 23:11:03 -05:00
Erik Desjardins
0d0cc4f6a0 AttrBuilder doesn't take a context in old LLVM 2022-02-26 17:16:01 -05:00
Erik Desjardins
ac9f4f7d0d use attrbuilder to remove attrs in old LLVM 2022-02-26 16:58:45 -05:00
Erik Desjardins
30d3ce0674 Add LLVM attributes in batches instead of individually
This should improve performance.
2022-02-26 13:14:55 -05:00
Matthias Krüger
0bb72a2c66
Rollup merge of #91675 - ivanloz:memtagsan, r=nagisa
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
2022-02-18 23:23:03 +01:00
Ivan Lozano
568aeda9e9 MemTagSanitizer Support
Adds support for the LLVM MemTagSanitizer.
2022-02-16 09:39:03 -05:00
Augie Fackler
0958c8f4ca llvm: migrate to new parameter-bearing uwtable attr
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.
2022-02-14 16:09:53 -05:00
Erik Desjardins
8cb0b6ca5b Apply noundef attribute to &T, &mut T, Box<T>, bool
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.
2022-02-05 01:09:52 -05:00
Eric Huss
e1eff1b0e8 Windows: Disable LLVM crash dialog boxes. 2022-01-27 16:53:17 -08:00
Jacob Bramley
e02e9582d2 Use error-on-mismatch policy for PAuth module flags.
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.
2022-01-24 16:50:10 +00:00
Amanieu d'Antras
606d9c0c0e Remove LLVMRustMarkAllFunctionsNounwind
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.
2022-01-14 00:36:12 +00:00
Matthias Krüger
1591dcb659
Rollup merge of #92559 - durin42:llvm-14-attributemask, r=nikic
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``
2022-01-06 23:15:18 +01:00
Augie Fackler
34a6b6c423 RustWrapper: simplify removing attributes
Avoids some extra conversions. Spotted by nikic during review.
2022-01-05 13:51:59 -05:00
Augie Fackler
2803fbc447 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.
2022-01-04 13:50:02 -05:00
Krasimir Georgiev
4ce56b414d RustWrapper: adapt for an LLVM API change
No functional changes intended.

The LLVM commit
ec501f15a8
removed the signed version of `createExpression`. This adapts the Rust
LLVM wrappers accordingly.
2022-01-03 11:25:33 +01:00
bors
4f49627c6f Auto merge of #92419 - erikdesjardins:coldland, r=nagisa
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
2022-01-01 13:28:13 +00:00
Erik Desjardins
e4463b2453 keep noinline for system llvm < 14 2021-12-30 00:15:51 -05:00
Axel Cohen
c4f29fa0ed Use the existing llvm-plugins option for both legacy and new pm registration 2021-12-13 10:41:43 +01:00
Axel Cohen
97cf461b8f Add a codegen option to allow loading LLVM pass plugins 2021-12-13 10:40:44 +01:00
cynecx
91021de1f6 LLVM codgen support for unwinding inline assembly 2021-12-03 23:51:49 +01:00
cynecx
491dd1f387 Adjust llvm wrapper for unwinding support for inlineasm 2021-12-03 23:51:49 +01:00
Matthias Krüger
d93df5775c
Rollup merge of #91207 - richkadel:rk-bump-coverage-version, r=tmandry
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=.`
2021-12-01 10:50:20 +01:00
Matthias Krüger
67762ffe35
Rollup merge of #90833 - tmiasko:optimization-remarks, r=nikic
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`
2021-11-28 23:45:17 +01:00
Arpad Borsos
566ad8da45 Update CoverageMappingFormat Support to Version6
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.
2021-11-23 15:49:03 -08:00
Benjamin A. Bjørnseth
bb9dee95ed add rustc option for using LLVM stack smash protection
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.
2021-11-22 20:06:22 +01:00
Josh Stone
023cc968e1 Make LLVMRustGetOrInsertGlobal always return a GlobalVariable
`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.
2021-11-19 19:33:29 -08:00
Tomasz Miąsko
8fa45295f4 Recognize machine optimization remarks 2021-11-16 08:19:20 +01:00
Tomasz Miąsko
6846674c75 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.
2021-11-16 08:19:20 +01:00
Krasimir Georgiev
d9f2d5f0e9 PassWrapper: additional sanitizer update to match clang
This happened later in the stream than the other changes, but the fix is
overlapping. Fix taken from a55c4ec1cee7683d9095327d9d33e7137ec25292 in
LLVM.
2021-11-11 09:05:21 -05:00
Augie Fackler
d440ce6a9f Didn't mean to invert this boolean. 2021-11-09 10:18:13 -05:00
Augie Fackler
6234a56949 rustc_llvm: update PassWrapper for recent LLVM
Now AddressSanitizerOptions is a struct, but at least the change was
tiny.

r? nikic
2021-11-09 10:18:13 -05:00
Tomasz Miąsko
5a09e12135 Initialize LLVM time trace profiler on each code generation thread
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.
2021-11-05 17:47:11 +01:00
Matthias Krüger
2f67647606
Rollup merge of #89581 - jblazquez:master, r=Mark-Simulacrum
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.
2021-10-25 22:59:46 +02:00
Josh Stone
e9f545b9a9 Update the minimum external LLVM to 12 2021-10-22 10:50:07 -07:00
Josh Stone
65150af1b4 Update the minimum external LLVM to 11 2021-10-22 09:22:18 -07:00
Krasimir Georgiev
e3c3f4a09c RustWrapper: adapt for an LLVM API change
No functional changes intended.

The LLVM commit
89b57061f7
moved TargetRegistry.(h|cpp) from Support to MC.
This adapts RustWrapper accordingly.
2021-10-18 09:48:47 +02:00
Javier Blazquez
4ed846ad4d 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
(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.
2021-10-11 12:09:32 -07:00
Jubilee
6c17601a2e
Rollup merge of #89025 - ricobbe:raw-dylib-link-ordinal, r=michaelwoerister
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.
2021-10-07 20:26:11 -07:00
Jubilee
6c2d4bf3f7
Rollup merge of #87918 - mikebenfield:pr-afdo, r=nikic
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.
2021-10-07 20:26:09 -07:00
Michael Benfield
a17193dbb9 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 -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.
2021-10-06 19:36:52 +00:00
Krasimir Georgiev
67a82e20cf RustWrapper: adapt for LLVM API change of fatal_error_handler_t
No functional changes intended.

The LLVM commit
e463b69736
changed an argument of fatal_error_handler_t from std::string to char*.
This adapts RustWrapper accordingly.
2021-10-05 16:31:36 +02:00
Augie Fackler
12c3f50a90 PassWrapper: handle function rename from upstream D36850
thinLTOResolvePrevailingInModule became thinLTOFinalizeInModule and
gained the ability to propagate noRecurse and noUnwind function
attributes. I ran codegen tests with it both on and off, as the upstream
patch uses it in both modes, and the tests pass both ways. Given that,
it seemed reasonable to go ahead and let the propagation be enabled in
rustc, and see what happens. See https://reviews.llvm.org/D36850 for
more examples of how the new version of the function gets used.
2021-09-27 18:11:21 -04:00
Nikita Popov
074bbc6b87 Use correct pipeline for LTO at O0
Unlike the pre-link piplines, the LTO pipelines do support O0,
and using them is required to avoid leaving behind undefined
references for the linker.
2021-09-25 11:24:23 +02:00
the8472
1deef1f75d
Rollup merge of #89041 - sticnarf:sticnarf/fat-lto-dwarf, r=nagisa
Work around invalid DWARF bugs for fat LTO

This PR applies the same workaround in #46772 to fat LTO.

It seems to fix the bug reported in https://github.com/rust-lang/rust/issues/66118#issuecomment-917434036.
2021-09-22 19:03:21 +02:00
Richard Cobbe
142f6c0b07 Implement #[link_ordinal] attribute in the context of #[link(kind = "raw-dylib")]. 2021-09-20 14:50:35 -07:00
Yilin Chen
d5de680e20 Work around invalid DWARF bugs for fat LTO
Signed-off-by: Yilin Chen <sticnarf@gmail.com>
2021-09-17 23:19:38 +08:00