Commit Graph

129 Commits

Author SHA1 Message Date
Augie Fackler
532bb80f7f RustWrapper: avoid deleted unclear attribute methods
These were deleted in https://reviews.llvm.org/D108614, and in C++ I
definitely see the argument for their removal. I didn't try and
propagate the changes up into higher layers of rustc in this change
because my initial goal was to get rustc working against LLVM HEAD
promptly, but I'm happy to follow up with some refactoring to make the
API on the Rust side match the LLVM API more directly (though the way
the enum works in Rust makes the API less scary IMO).

r? @nagisa cc @nikic
2021-09-07 15:30:42 -04:00
Augie Fackler
027db5d036 RustWrapper: adapt to LLVM change 0f45c16f2caa
The above-mentioned commit (part of the LLVM 14 development cycle)
removes a method that rustc uses somewhat extensively. We mostly switch
to lower-level methods that exist in all versions of LLVM we use, so no
new ifdef logic is required in most cases.
2021-08-26 10:40:27 -04:00
Guillaume Gomez
2638d27ba5
Rollup merge of #88164 - durin42:llvm-14-san-opts, r=nikic
PassWrapper: adapt for LLVM 14 changes

These API changes appear to have all taken place in
https://reviews.llvm.org/D105007, which moved HWAddressSanitizerPass and
AddressSanitizerPass to only accept their options type as a ctor
argument instead of the sequence of bools etc. This required a couple of
parameter additions, which I made match the default prior to the
mentioned upstream LLVM change.

This patch restores rustc to building (though not quite passing all
tests, I've mailed other patches for those issues) against LLVM HEAD.
2021-08-22 20:52:53 +02:00
Augie Fackler
c4e6185385 PassWrapper: adapt for LLVM 14 changes
These API changes appear to have all taken place in
https://reviews.llvm.org/D105007, which moved HWAddressSanitizerPass and
AddressSanitizerPass to only accept their options type as a ctor
argument instead of the sequence of bools etc. This required a couple of
parameter additions, which I made match the default prior to the
mentioned upstream LLVM change.

This patch restores rustc to building (though not quite passing all
tests, I've mailed other patches for those issues) against LLVM HEAD.
2021-08-19 12:44:54 -04:00
Nikita Popov
621f5146c3 Handle SrcMgr diagnostics
This is how InlineAsm diagnostics with source information are
reported now. Previously a separate InlineAsm diagnostic handler
was used.
2021-08-16 18:28:17 +02:00
bors
2d10c2a330 Auto merge of #87798 - durin42:llvm-14, r=nikic
PassWrapper: handle move of OptimizationLevel class out of PassBuilder

This is the first build break of the LLVM 14 cycle, and was caused by
https://reviews.llvm.org/D107025. Mercifully an easy fix.
2021-08-08 04:33:22 +00:00
Augie Fackler
482f1901b0 PassWrapper: handle move of OptimizationLevel class out of PassBuilder
This is the first build break of the LLVM 14 cycle, and was caused by
https://reviews.llvm.org/D107025. Mercifully an easy fix.
2021-08-06 18:08:04 -04:00
Josh Stone
183d79cc09 Prepare call/invoke for opaque pointers
Rather than relying on `getPointerElementType()` from LLVM function
pointers, we now pass the function type explicitly when building `call`
or `invoke` instructions.
2021-08-05 10:58:55 -07:00
Tomasz Miąsko
8e0df32ad6 Replace LLVMConstInBoundsGEP with LLVMConstInBoundsGEP2*
A custom reimplementation of LLVMConstInBoundsGEP2 is used, since the
LLVM contains a declaration of LLVMConstInBoundsGEP2 but not the
implementation.
2021-08-04 15:51:30 +02:00
bors
b53a93db2d Auto merge of #87535 - lf-:authors, r=Mark-Simulacrum
rfc3052 followup: Remove authors field from Cargo manifests

Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
2021-08-02 05:49:17 +00:00
Yuki Okushi
9391d55204
Rollup merge of #86072 - MarcusCalhoun-Lopez:llvm_cross, r=nagisa
Cross compiling rustc_llvm on Darwin requires zlib.
2021-07-31 04:09:19 +09:00
Jade
3cf820e17d rfc3052: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
2021-07-29 14:56:05 -07:00
Yuki Okushi
e457c2739b
Upgrade cc crate to 1.0.69 2021-07-13 17:58:50 +09:00
Nikita Popov
33e9a6b565 Pass type when creating atomic load
Instead of determining it from the pointer type, explicitly pass
the type to load.
2021-07-09 22:00:19 +02:00
Marcus Calhoun-Lopez
956fd10660 Cross compiling rustc_llvm on Darwin requires zlib. 2021-06-26 07:29:57 -07:00
bors
9a576175cc Auto merge of #84171 - ricobbe:raw-dylib-via-llvm, r=petrochenkov
Partial support for raw-dylib linkage

First cut of functionality for issue #58713: add support for `#[link(kind = "raw-dylib")]` on `extern` blocks in lib crates compiled to .rlib files.  Does not yet support `#[link_name]` attributes on functions, or the `#[link_ordinal]` attribute, or `#[link(kind = "raw-dylib")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps.  It's also not yet clear whether this works for functions in `extern "stdcall"` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR.

This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.
2021-06-06 03:59:17 +00:00
bors
f434217aab Auto merge of #79608 - alessandrod:bpf, r=nagisa
BPF target support

This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.

I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
2021-06-06 01:02:32 +00:00
Richard Cobbe
6aa45b71b1 Add first cut of functionality for #58713: support for #[link(kind = "raw-dylib")].
This does not yet support #[link_name] attributes on functions, the #[link_ordinal]
attribute, #[link(kind = "raw-dylib")] on extern blocks in bin crates, or
stdcall functions on 32-bit x86.
2021-06-04 18:01:35 -07:00
Alex Crichton
0e0338744d rustc: Store metadata-in-rlibs in object files
This commit updates how rustc compiler metadata is stored in rlibs.
Previously metadata was stored as a raw file that has the same format as
`--emit metadata`. After this commit, however, the metadata is encoded
into a small object file which has one section which is the contents of
the metadata.

The motivation for this commit is to fix a common case where #83730
arises. The problem is that when rustc crates a `dylib` crate type it
needs to include entire rlib files into the dylib, so it passes
`--whole-archive` (or the equivalent) to the linker. The problem with
this, though, is that the linker will attempt to read all files in the
archive. If the metadata file were left as-is (today) then the linker
would generate an error saying it can't read the file. The previous
solution was to alter the rlib just before linking, creating a new
archive in a temporary directory which has the metadata file removed.

This problem from before this commit is now removed if the metadata file
is stored in an object file that the linker can read. The only caveat we
have to take care of is to ensure that the linker never actually
includes the contents of the object file into the final output. We apply
similar tricks as the `.llvmbc` bytecode sections to do this.

This involved changing the metadata loading code a bit, namely updating
some of the LLVM C APIs used to use non-deprecated ones and fiddling
with the lifetimes a bit to get everything to work out. Otherwise though
this isn't intended to be a functional change really, only that metadata
is stored differently in archives now.

This should end up fixing #83730 because by default dylibs will no
longer have their rlib dependencies "altered" meaning that
split-debuginfo will continue to have valid paths pointing at the
original rlibs. (note that we still "alter" rlibs if LTO is enabled to
remove Rust object files and we also "alter" for the #[link(cfg)]
feature, but that's rarely used).

Closes #83730
2021-06-04 10:05:20 -07:00
Chris Denton
e238ee31d4
Update cc
Recent commits to cc have helped to address #83043 and #43468
2021-05-24 23:34:12 +01:00
Alessandro Decina
12e70929d6 Add BPF target
This change adds the bpfel-unknown-none and bpfeb-unknown-none targets
which can be used to generate little endian and big endian BPF
2021-05-23 18:03:27 +10:00
bors
fc81ad22c4 Auto merge of #85416 - durin42:llvm-catchup-may-2021, r=nagisa
PassWrapper: update for LLVM change D102093

In https://reviews.llvm.org/D102093 lots of things stopped taking the
DebugLogging boolean parameter. Mercifully we appear to always set
DebugPassManager to false, so I don't think we're losing anything by not
passing this parameter.
2021-05-21 11:21:06 +00:00
Augie Fackler
445658ba6d PassWrapper: update for LLVM change D102093
In https://reviews.llvm.org/D102093 lots of things stopped taking the
DebugLogging boolean parameter. Mercifully we appear to always set
DebugPassManager to false, so I don't think we're losing anything by not
passing this parameter.
2021-05-17 14:14:34 -04:00
bors
91f2e2d218 Auto merge of #85190 - mati865:update-cc, r=Mark-Simulacrum
Update cc crate

To pull in this fix: 801a87bf2f
2021-05-14 04:12:40 +00:00
Mateusz Mikuła
b04fd78d66 update cc crate
To pull in this fix: 801a87bf2f
2021-05-12 00:55:03 +02:00
Nikita Popov
c2b15a6b64 Support -C passes in NewPM
And report an error if parsing the additional pass pipeline fails.
Threading through the error accounts for most of the changes here.
2021-05-08 10:58:08 +02:00
Nikita Popov
db140de8f2 Explicitly register GCOV profiling pass as well 2021-05-08 10:58:08 +02:00
Nikita Popov
5ecbe7fcf8 Explicitly register instrprof pass
Don't use "passes" for this purpose, explicitly insert it into
the correct place in the pipeline instead.
2021-05-08 10:58:08 +02:00
Fangrui Song
0142d1cb97 Replace llvm::sys::fs::F_None with llvm::sys::fs::OF_None
The former is deprecated.
OF_None has been available in LLVM since 2018-06.
2021-04-29 15:25:17 -07:00
Augie Fackler
fc2a74c640 RustWrapper: work around unification of diagnostic handlers
This lets me build against llvm/main as of March 23rd, 2021. I'm not
entirely sure this is _correct_, but it appears to be functionally
identical to what was done in LLVM: existing callsites of
setInlineAsmDiagnosticHandler were moved to SetDiagnosticHandler() on
the context object, which we already set up in both places that we
called setInlineAsmDiagnosticHandler().
2021-04-22 15:46:47 -04:00
Simonas Kazlauskas
487e27350a Don't set fast(-math) for certain simd ops
`fast-math` implies things like functions not being able to accept as an
argument or return as a result, say, `inf` which made these functions
confusingly named or behaving incorrectly, depending on how you
interpret it. Since the time when these intrinsics have been implemented
the intrinsics user's (stdsimd) approach has changed significantly and
so now it is required that these intrinsics operate normally rather than
in "whatever" way.

Fixes #84268
2021-04-17 23:33:10 +03:00
Matt Ickstadt
e258a5ba6e Categorize and explain target features support 2021-04-09 10:16:04 -05:00
Simonas Kazlauskas
2f000a78bf Manually set dso_local when its valid to do so
This should have no real effect in most cases, as e.g. `hidden`
visibility already implies `dso_local` (or at least LLVM IR does not
preserve the `dso_local` setting if the item is already `hidden`), but
it should fix `-Crelocation-model=static` and improve codegen in
executables.

Note that this PR does not exhaustively port the logic in [clang]. Only
the obviously correct portion and what is necessary to fix a regression
from LLVM 12 that relates to `-Crelocation_model=static`.

Fixes #83335

[clang]: 3001d080c8/clang/lib/CodeGen/CodeGenModule.cpp (L945-L1039)
2021-04-03 00:00:29 +03:00
bors
6e17a5c5fd Auto merge of #83387 - cuviper:min-llvm-10, r=nagisa
Update the minimum external LLVM to 10

r? `@nikic`
2021-03-25 13:11:18 +00:00
Augie Fackler
04961d2405 LLVMWrapper: attractive nuisance macros
THis came up in the review of #83425: it's hard to imagine a use of
LLVM_VERSION_LE() or LLVM_VERSION_EQ() that's not asking for trouble
when a point release gets created, so let's just discard them to prevent
the issue.
2021-03-24 14:39:13 -04:00
Josh Stone
b97a33b1cb All supported LLVM versions have MSP430AsmPrinter 2021-03-22 12:44:48 -07:00
Augie Fackler
9431e8577d cleanup: add some comments per review feedback 2021-03-22 14:37:49 -04:00
Josh Stone
7d872f538e Update the minimum external LLVM to 10 2021-03-22 11:33:43 -07:00
Augie Fackler
babe894bab fix: I meant LLVM version 13, not 12 2021-03-19 16:46:40 -04:00
Augie Fackler
dcdb9ad3d2 llvm-wrapper: pass std::string instead of StringRef
LLVM change 5fbd1a333aa1a0b70903d036b98ea56c51ae5224 modified this
function to want std::string instead of StringRef, which is easily done.
2021-03-16 17:13:20 -04:00
Augie Fackler
0ed1c33ad9 llvm-wrapper: add alignment argument to CreateAtomicCmpXchg
As far as I can tell what we've been getting is llvm::MaybeAlign(), so
just use that for now. This is required sometime after
24539f1ef2471d07bd87f833cb0288fc0f251f4b.
2021-03-16 17:13:13 -04:00
Augie Fackler
af95484778 llvm-wrapper: adapt to function signature change of thinLTOResolvePrevailingInIndex
This changed in 54fb3ca96e261f7107cb1b5778c34cb0e0808be6 - I'm not
entirely sure it's correct that we're leaving config empty, but the one
case in LLVM that looked similar did that.
2021-03-16 16:45:21 -04:00
bors
84c08f82b4 Auto merge of #83044 - kubo39:set-llvm-code-model, r=nikic
Add support for storing code model to LLVM module IR

This patch avoids undefined behavior by linking different object files.
Also this would it could be propagated properly to LTO.

See https://reviews.llvm.org/D52322 and https://reviews.llvm.org/D52323.

This patch is based on https://github.com/rust-lang/rust/pull/74002
2021-03-14 11:46:57 +00:00
Hiroki Noda
8357e57346 Add support for storing code model to LLVM module IR
This patch avoids undefined behavior by linking different object files.
Also this would it could be propagated properly to LTO.

See https://reviews.llvm.org/D52322 and https://reviews.llvm.org/D52323.

This patch is based on https://github.com/rust-lang/rust/pull/74002
2021-03-12 11:02:25 +09:00
Hiroki Noda
65ed23c282 Support merge_functions option in NewPM since LLVM >= 12
now we can pass this flag since https://reviews.llvm.org/D93002 has been
merged.
2021-03-12 08:16:10 +09:00
Nikita Popov
9a8acea783 Schedule ThinLTOBuffer passes again after sanitizer passes
This works around a design defect in the LLVM 12 pass builder
implementation. In LLVM 13, the PreLink ThinLTO pipeline properly
respects the OptimizerLastEPCallbacks.
2021-03-03 20:48:37 +01:00
Nikita Popov
bc96516a28 Mark pure asm as willreturn 2021-03-01 23:35:35 +01:00
Nikita Popov
1d280b012d Don't directly expose coverage::CounterMappingRegion via FFI
The definition of this struct changes in LLVM 12 due to the addition
of branch coverage support. To avoid future mismatches, declare our
own struct and then convert between them.
2021-03-01 23:35:35 +01:00
Nikita Popov
55f345f325 Support LLVM 12 in rustc 2021-02-28 10:19:44 +01:00
Tri Vo
c7d9bffe76 HWASan support 2021-02-07 23:48:58 -08:00
Hugues de Valon
ce9818f2b7 Add a new ABI to support cmse_nonsecure_call
This commit adds a new ABI to be selected via `extern
"C-cmse-nonsecure-call"` on function pointers in order for the compiler to
apply the corresponding cmse_nonsecure_call callsite attribute.
For Armv8-M targets supporting TrustZone-M, this will perform a
non-secure function call by saving, clearing and calling a non-secure
function pointer using the BLXNS instruction.

See the page on the unstable book for details.

Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
2021-02-02 13:04:31 +00:00
Erik Desjardins
cd25807223 Use probe-stack=inline-asm in LLVM 11+ 2021-01-14 22:49:16 -05:00
Josh Stone
0342fd16ff Remove the unused context from CreateDebugLocation
This went unused in commit 88d874de63, part of #68965.
2021-01-13 11:55:49 -08:00
Mark Rousskov
8a3edb1d66 Update tests for extern block linting 2021-01-13 07:49:16 -05:00
David Wood
341aa97adb
llvm: update ffi bindings for split dwarf
This commit modifies the FFI bindings to LLVM required for Split DWARF
support in rustc. In particular:

- `addPassesToEmitFile`'s wrapper, `LLVMRustWriteOutputFile` now takes
  a `DwoPath` `const char*`. When disabled, `nullptr` should be provided
  which will preserve existing behaviour. When enabled, the path to the
  `.dwo` file should be provided.
- `createCompileUnit`'s wrapper, `LLVMRustDIBuilderCreateCompileUnit`
  now has two additional arguments, for the `DWOId` and to enable
  `SplitDebugInlining`. `DWOId` should always be zero.
- `createTargetMachine`'s wrapper, `LLVMRustCreateTargetMachine` has an
  additional argument which should be provided the path to the `.dwo`
  when enabled.

Signed-off-by: David Wood <david@davidtw.co>
2020-12-16 10:31:42 +00:00
Matthias Krüger
5c8de1cf49 use strip_prefix over slicing (clippy::manual_strip) 2020-12-11 23:02:17 +01:00
bors
6645da366e Auto merge of #78684 - devsnek:inline-asm-wasm, r=Amanieu
Add wasm32 support to inline asm

There is some contention around inline asm and wasm, and I really only made this to figure out the process of hacking on rustc, but I figured as long as the code existed, it was worth uploading.

cc `@Amanieu`
2020-12-01 20:23:06 +00:00
Gus Caplan
d9f237caa6
Add wasm32 support to inline asm 2020-12-01 12:18:21 -06:00
Rich Kadel
b4668ecb73 Improved version check 2020-11-25 09:45:33 -08:00
Rich Kadel
51268d2735 Check for LLVM 11+ when using -Z instrument-coverage
* `rustc` should now compile under LLVM 9 or 10
* Compiler generates an error if `-Z instrument-coverage` is specified
  but LLVM version is less than 11
* Coverage tests that require `-Z instrument-coverage` and run codegen
  should be skipped if LLVM version is less than 11
2020-11-24 11:50:24 -08:00
Rich Kadel
1d8c381c01 Upgrades the coverage map to Version 4
Changes the coverage map injected into binaries compiled with
`-Zinstrument-coverage` to LLVM Coverage Mapping Format, Version 4 (from
Version 3). Note, binaries compiled with this version will require LLVM
tools from at least LLVM Version 11.
2020-11-23 15:14:47 -08:00
DevJPM
b51bcc72d9 fully exploited the dropped support of LLVM 8
This commit grepped for LLVM_VERSION_GE, LLVM_VERSION_LT, get_major_version and
min-llvm-version and statically evaluated every expression possible
(and sensible) assuming that the LLVM version is >=9 now
2020-11-12 14:39:47 +01:00
Mara Bos
52405f7c0c
Rollup merge of #77950 - arlosi:sha256, r=eddyb
Add support for SHA256 source file hashing

Adds support for `-Z src-hash-algorithm sha256`, which became available in LLVM 11.

Using an older version of LLVM will cause an error `invalid checksum kind` if the hash algorithm is set to sha256.

r? `@eddyb`
cc #70401 `@est31`
2020-11-03 19:32:26 +01:00
bors
1e37ba76d4 Auto merge of #78531 - cuviper:unwrap-metadata, r=tmandry
rustc_llvm: unwrap LLVMMetadataRef before casting

Directly casting the opaque pointer was [reported] to cause an
"incomplete type" error with GCC 9.3:

```
llvm-wrapper/RustWrapper.cpp:939:31:   required from here
/usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata'
 1301 |     struct is_base_of
      |            ^~~~~~~~~~
In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23,
                 from llvm-wrapper/LLVMWrapper.h:1,
                 from llvm-wrapper/RustWrapper.cpp:1:
[...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata'
   89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef;
      |                ^~~~~~~~~~~~~~~~~~
```

[reported]: https://zulip-archive.rust-lang.org/182449tcompilerhelp/12215halprustcllvmbuildfail.html#214915124

A simple `unwrap` fixes the issue.

r? `@eddyb`
2020-11-01 09:30:11 +00:00
Josh Stone
dcbf2f324f rustc_llvm: unwrap LLVMMetadataRef before casting
Directly casting the opaque pointer was [reported] to cause an
"incomplete type" error with GCC 9.3:

```
llvm-wrapper/RustWrapper.cpp:939:31:   required from here
/usr/include/c++/9.3/type_traits:1301:12: error: invalid use of incomplete type 'struct LLVMOpaqueMetadata'
 1301 |     struct is_base_of
      |            ^~~~~~~~~~
In file included from [...]/rust/src/llvm-project/llvm/include/llvm-c/BitReader.h:23,
                 from llvm-wrapper/LLVMWrapper.h:1,
                 from llvm-wrapper/RustWrapper.cpp:1:
[...]/rust/src/llvm-project/llvm/include/llvm-c/Types.h:89:16: note: forward declaration of 'struct LLVMOpaqueMetadata'
   89 | typedef struct LLVMOpaqueMetadata *LLVMMetadataRef;
      |                ^~~~~~~~~~~~~~~~~~
```

[reported]: https://zulip-archive.rust-lang.org/182449tcompilerhelp/12215halprustcllvmbuildfail.html#214915124

A simple `unwrap` fixes the issue.
2020-10-29 09:45:15 -07:00
Jonas Schievink
38c34098b1
Rollup merge of #78462 - danielframpton:fixnullisa, r=nagisa
Use unwrapDIPtr because the Scope may be null.

I ran into an assertion when using debug information on Windows with LLVM assertions enabled.

It seems like we are using unwrap here (which in turn calls isa and requires the pointer to be non-null) but we expect the value to be null because that is what we are passing from rustc.

This change uses unwrapDIPtr which explicitly allows nullptr.

The FFI prototype for this method on the rust side has the `LLVMMetadataRef` parameter as `Scope: Option<&'a DIScope>`, and we always pass `None` when `msvc_like_names` is true.
2020-10-29 17:05:23 +01:00
Daniel Frampton
a3bff69134 Use unwrapDIPtr because the Scope may be passed as None 2020-10-27 18:05:16 -07:00
Eduard-Mihai Burtescu
88d874de63 rustc_codegen_llvm: avoid converting between DILocation and Value. 2020-10-21 04:43:57 +03:00
Eduard-Mihai Burtescu
fa2b381ec8 rustc_codegen_llvm: move DISubprogram creation to a dbg_scope_fn method. 2020-10-21 04:43:57 +03:00
Arlo Siemsen
3296d5ca7b Add support for SHA256 source file hashing for LLVM 11+. 2020-10-14 15:09:51 -07:00
bors
c71248b708 Auto merge of #76859 - Aaron1011:fix/llvm-cgu-reuse, r=davidtwco,nikic
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse

During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.

Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.

However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.

Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.

The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.

In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.

This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-10-11 20:50:02 +00:00
est31
8b8e706008 Simplify some code in rustc_llvm/build.rs now that LLVM 8 is required
LLVM 8 is required since 8506bb0060
so this is safe to do.
2020-10-08 06:19:06 +02:00
Hugues de Valon
d255d70e7a Update LLVM and add Unsupported diagnostic
Secure entry functions do not support if arguments are passed on the
stack. An "unsupported" diagnostic will be emitted by LLVM if that is
the case.
This commits adds support in Rust for that diagnostic so that an error
will be output if that is the case!

Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
2020-09-30 14:57:37 +01:00
est31
12187b7f86 Remove unused #[allow(...)] statements from compiler/ 2020-09-26 01:25:55 +02:00
Erik Hofmayer
138a2e5eaa /nightly/nightly-rustc 2020-09-23 21:51:56 +02:00
Erik Hofmayer
dd66ea2d3d Updated html_root_url for compiler crates 2020-09-23 21:14:43 +02:00
Jake Goulding
9803c9b252 Update cc crate to understand aarch64-apple-darwin with clang 2020-09-18 09:22:07 -04:00
Aaron Hill
cfe07cd42a
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.

Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.

However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.

Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.

The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.

In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.

This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-09-17 22:04:13 -04:00
Vadim Petrochenkov
10d3f8a484 Move rustllvm into rustc_llvm 2020-09-09 23:05:43 +03:00