Commit graph

25 commits

Author SHA1 Message Date
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