2015-02-28 21:53:12 +00:00
|
|
|
//! Set and unset common attributes on LLVM values.
|
|
|
|
|
2018-08-07 14:03:57 +00:00
|
|
|
use std::ffi::CString;
|
2016-11-30 00:02:00 +00:00
|
|
|
|
2021-02-13 11:17:15 +00:00
|
|
|
use cstr::cstr;
|
2019-12-22 22:42:04 +00:00
|
|
|
use rustc_codegen_ssa::traits::*;
|
|
|
|
use rustc_data_structures::small_c_str::SmallCStr;
|
2020-10-09 17:35:17 +00:00
|
|
|
use rustc_hir::def_id::DefId;
|
2020-03-29 15:19:48 +00:00
|
|
|
use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags;
|
|
|
|
use rustc_middle::ty::layout::HasTyCtxt;
|
2020-03-31 12:27:09 +00:00
|
|
|
use rustc_middle::ty::{self, TyCtxt};
|
2021-02-07 21:47:03 +00:00
|
|
|
use rustc_session::config::OptLevel;
|
2020-03-11 11:49:08 +00:00
|
|
|
use rustc_session::Session;
|
rustc: Add a new `wasm` ABI
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.
When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.
Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.
To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.
With the addition of a new ABI, this enables rustc to:
* Eventually remove the "wasm-bindgen compat hack". Once this
ABI is stable wasm-bindgen can switch to using it everywhere.
Afterwards the wasm32-unknown-unknown target can have its default ABI
updated to match C.
* Expose the ability to precisely match an ABI signature for a
WebAssembly function, regardless of what the C ABI that clang chooses
turns out to be.
* Continue to evolve the definition of the default C ABI to match what
clang does on all targets, since the purpose of that ABI will be
explicitly matching C rather than generating particular function
imports/exports.
Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
2021-04-01 23:08:29 +00:00
|
|
|
use rustc_target::spec::abi::Abi;
|
2021-02-07 21:47:03 +00:00
|
|
|
use rustc_target::spec::{SanitizerSet, StackProbeType};
|
2017-06-21 19:08:18 +00:00
|
|
|
|
2019-02-17 18:58:58 +00:00
|
|
|
use crate::attributes;
|
|
|
|
use crate::llvm::AttributePlace::Function;
|
2019-12-22 22:42:04 +00:00
|
|
|
use crate::llvm::{self, Attribute};
|
2019-02-17 18:58:58 +00:00
|
|
|
use crate::llvm_util;
|
2020-10-08 22:23:27 +00:00
|
|
|
pub use rustc_attr::{InlineAttr, InstructionSetAttr, OptimizeAttr};
|
2018-07-10 10:28:39 +00:00
|
|
|
|
2019-02-17 18:58:58 +00:00
|
|
|
use crate::context::CodegenCx;
|
|
|
|
use crate::value::Value;
|
2015-02-28 21:53:12 +00:00
|
|
|
|
|
|
|
/// Mark LLVM function to use provided inline heuristic.
|
|
|
|
#[inline]
|
2020-11-20 00:00:00 +00:00
|
|
|
fn inline(cx: &CodegenCx<'ll, '_>, val: &'ll Value, inline: InlineAttr) {
|
2015-03-03 23:03:25 +00:00
|
|
|
use self::InlineAttr::*;
|
2015-02-28 21:53:12 +00:00
|
|
|
match inline {
|
2019-12-22 22:42:04 +00:00
|
|
|
Hint => Attribute::InlineHint.apply_llfn(Function, val),
|
2016-08-02 21:25:19 +00:00
|
|
|
Always => Attribute::AlwaysInline.apply_llfn(Function, val),
|
2019-12-22 22:42:04 +00:00
|
|
|
Never => {
|
2020-10-15 09:44:00 +00:00
|
|
|
if cx.tcx().sess.target.arch != "amdgpu" {
|
2018-07-19 03:04:27 +00:00
|
|
|
Attribute::NoInline.apply_llfn(Function, val);
|
|
|
|
}
|
2019-12-22 22:42:04 +00:00
|
|
|
}
|
2020-11-17 00:00:00 +00:00
|
|
|
None => {}
|
2015-02-28 21:53:12 +00:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2020-01-16 00:00:00 +00:00
|
|
|
/// Apply LLVM sanitize attributes.
|
|
|
|
#[inline]
|
2020-06-14 00:00:00 +00:00
|
|
|
pub fn sanitize(cx: &CodegenCx<'ll, '_>, no_sanitize: SanitizerSet, llfn: &'ll Value) {
|
|
|
|
let enabled = cx.tcx.sess.opts.debugging_opts.sanitizer - no_sanitize;
|
|
|
|
if enabled.contains(SanitizerSet::ADDRESS) {
|
|
|
|
llvm::Attribute::SanitizeAddress.apply_llfn(Function, llfn);
|
|
|
|
}
|
|
|
|
if enabled.contains(SanitizerSet::MEMORY) {
|
|
|
|
llvm::Attribute::SanitizeMemory.apply_llfn(Function, llfn);
|
|
|
|
}
|
|
|
|
if enabled.contains(SanitizerSet::THREAD) {
|
|
|
|
llvm::Attribute::SanitizeThread.apply_llfn(Function, llfn);
|
2020-01-16 00:00:00 +00:00
|
|
|
}
|
2021-01-23 02:32:38 +00:00
|
|
|
if enabled.contains(SanitizerSet::HWADDRESS) {
|
|
|
|
llvm::Attribute::SanitizeHWAddress.apply_llfn(Function, llfn);
|
|
|
|
}
|
2020-01-16 00:00:00 +00:00
|
|
|
}
|
|
|
|
|
2015-02-28 21:53:12 +00:00
|
|
|
/// Tell LLVM to emit or not emit the information necessary to unwind the stack for the function.
|
|
|
|
#[inline]
|
2018-07-10 10:28:39 +00:00
|
|
|
pub fn emit_uwtable(val: &'ll Value, emit: bool) {
|
2016-08-02 21:25:19 +00:00
|
|
|
Attribute::UWTable.toggle_llfn(Function, val, emit);
|
2015-02-28 21:53:12 +00:00
|
|
|
}
|
|
|
|
|
2018-11-27 02:59:49 +00:00
|
|
|
/// Tell LLVM if this function should be 'naked', i.e., skip the epilogue and prologue.
|
2016-03-21 20:01:08 +00:00
|
|
|
#[inline]
|
2019-11-27 10:55:33 +00:00
|
|
|
fn naked(val: &'ll Value, is_naked: bool) {
|
2016-08-02 21:25:19 +00:00
|
|
|
Attribute::Naked.toggle_llfn(Function, val, is_naked);
|
2016-03-21 20:01:08 +00:00
|
|
|
}
|
|
|
|
|
2018-07-10 10:28:39 +00:00
|
|
|
pub fn set_frame_pointer_elimination(cx: &CodegenCx<'ll, '_>, llfn: &'ll Value) {
|
2018-01-05 05:04:08 +00:00
|
|
|
if cx.sess().must_not_eliminate_frame_pointers() {
|
2020-04-14 19:10:58 +00:00
|
|
|
llvm::AddFunctionAttrStringValue(
|
|
|
|
llfn,
|
|
|
|
llvm::AttributePlace::Function,
|
2021-02-13 11:17:15 +00:00
|
|
|
cstr!("frame-pointer"),
|
|
|
|
cstr!("all"),
|
2020-04-14 19:10:58 +00:00
|
|
|
);
|
rustc: Update LLVM
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
2015-05-14 19:10:43 +00:00
|
|
|
}
|
2016-05-27 17:27:56 +00:00
|
|
|
}
|
|
|
|
|
2018-12-30 19:59:03 +00:00
|
|
|
/// Tell LLVM what instrument function to insert.
|
|
|
|
#[inline]
|
2019-11-27 10:55:33 +00:00
|
|
|
fn set_instrument_function(cx: &CodegenCx<'ll, '_>, llfn: &'ll Value) {
|
2018-12-30 19:59:03 +00:00
|
|
|
if cx.sess().instrument_mcount() {
|
|
|
|
// Similar to `clang -pg` behavior. Handled by the
|
|
|
|
// `post-inline-ee-instrument` LLVM pass.
|
2019-03-28 21:44:31 +00:00
|
|
|
|
|
|
|
// The function name varies on platforms.
|
|
|
|
// See test/CodeGen/mcount.c in clang.
|
2020-11-08 11:57:55 +00:00
|
|
|
let mcount_name = CString::new(cx.sess().target.mcount.as_str().as_bytes()).unwrap();
|
2019-03-28 21:44:31 +00:00
|
|
|
|
2018-12-30 19:59:03 +00:00
|
|
|
llvm::AddFunctionAttrStringValue(
|
2019-12-22 22:42:04 +00:00
|
|
|
llfn,
|
|
|
|
llvm::AttributePlace::Function,
|
2021-02-13 11:17:15 +00:00
|
|
|
cstr!("instrument-function-entry-inlined"),
|
2019-12-22 22:42:04 +00:00
|
|
|
&mcount_name,
|
|
|
|
);
|
2018-12-30 19:59:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-27 10:55:33 +00:00
|
|
|
fn set_probestack(cx: &CodegenCx<'ll, '_>, llfn: &'ll Value) {
|
2017-06-21 19:08:18 +00:00
|
|
|
// Currently stack probes seem somewhat incompatible with the address
|
2019-10-04 00:00:00 +00:00
|
|
|
// sanitizer and thread sanitizer. With asan we're already protected from
|
|
|
|
// stack overflow anyway so we don't really need stack probes regardless.
|
2020-06-14 00:00:00 +00:00
|
|
|
if cx
|
|
|
|
.sess()
|
|
|
|
.opts
|
|
|
|
.debugging_opts
|
|
|
|
.sanitizer
|
|
|
|
.intersects(SanitizerSet::ADDRESS | SanitizerSet::THREAD)
|
|
|
|
{
|
|
|
|
return;
|
2017-06-21 19:08:18 +00:00
|
|
|
}
|
|
|
|
|
2019-05-28 14:48:03 +00:00
|
|
|
// probestack doesn't play nice either with `-C profile-generate`.
|
|
|
|
if cx.sess().opts.cg.profile_generate.enabled() {
|
2018-02-19 00:57:55 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-06-20 21:07:55 +00:00
|
|
|
// probestack doesn't play nice either with gcov profiling.
|
|
|
|
if cx.sess().opts.debugging_opts.profile {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-01-09 14:54:20 +00:00
|
|
|
let attr_value = match cx.sess().target.stack_probes {
|
|
|
|
StackProbeType::None => None,
|
|
|
|
// Request LLVM to generate the probes inline. If the given LLVM version does not support
|
|
|
|
// this, no probe is generated at all (even if the attribute is specified).
|
2021-02-13 11:17:15 +00:00
|
|
|
StackProbeType::Inline => Some(cstr!("inline-asm")),
|
2021-01-09 14:54:20 +00:00
|
|
|
// Flag our internal `__rust_probestack` function as the stack probe symbol.
|
|
|
|
// This is defined in the `compiler-builtins` crate for each architecture.
|
2021-02-13 11:17:15 +00:00
|
|
|
StackProbeType::Call => Some(cstr!("__rust_probestack")),
|
2021-01-09 14:54:20 +00:00
|
|
|
// Pick from the two above based on the LLVM version.
|
|
|
|
StackProbeType::InlineOrCall { min_llvm_version_for_inline } => {
|
|
|
|
if llvm_util::get_version() < min_llvm_version_for_inline {
|
2021-02-13 11:17:15 +00:00
|
|
|
Some(cstr!("__rust_probestack"))
|
2021-01-09 14:54:20 +00:00
|
|
|
} else {
|
2021-02-13 11:17:15 +00:00
|
|
|
Some(cstr!("inline-asm"))
|
2021-01-09 14:54:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
if let Some(attr_value) = attr_value {
|
|
|
|
llvm::AddFunctionAttrStringValue(
|
|
|
|
llfn,
|
|
|
|
llvm::AttributePlace::Function,
|
2021-02-13 11:17:15 +00:00
|
|
|
cstr!("probe-stack"),
|
2021-01-09 14:54:20 +00:00
|
|
|
attr_value,
|
|
|
|
);
|
|
|
|
}
|
2017-06-21 19:08:18 +00:00
|
|
|
}
|
|
|
|
|
2018-08-22 15:48:32 +00:00
|
|
|
pub fn apply_target_cpu_attr(cx: &CodegenCx<'ll, '_>, llfn: &'ll Value) {
|
2018-12-07 18:51:03 +00:00
|
|
|
let target_cpu = SmallCStr::new(llvm_util::target_cpu(cx.tcx.sess));
|
2018-08-02 16:10:26 +00:00
|
|
|
llvm::AddFunctionAttrStringValue(
|
2019-12-22 22:42:04 +00:00
|
|
|
llfn,
|
|
|
|
llvm::AttributePlace::Function,
|
2021-02-13 11:17:15 +00:00
|
|
|
cstr!("target-cpu"),
|
2019-12-22 22:42:04 +00:00
|
|
|
target_cpu.as_c_str(),
|
|
|
|
);
|
2018-08-02 16:10:26 +00:00
|
|
|
}
|
|
|
|
|
2020-09-17 09:39:26 +00:00
|
|
|
pub fn apply_tune_cpu_attr(cx: &CodegenCx<'ll, '_>, llfn: &'ll Value) {
|
|
|
|
if let Some(tune) = llvm_util::tune_cpu(cx.tcx.sess) {
|
|
|
|
let tune_cpu = SmallCStr::new(tune);
|
|
|
|
llvm::AddFunctionAttrStringValue(
|
|
|
|
llfn,
|
|
|
|
llvm::AttributePlace::Function,
|
2021-02-13 11:17:15 +00:00
|
|
|
cstr!("tune-cpu"),
|
2020-09-17 09:39:26 +00:00
|
|
|
tune_cpu.as_c_str(),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-26 16:19:55 +00:00
|
|
|
/// Sets the `NonLazyBind` LLVM attribute on a given function,
|
|
|
|
/// assuming the codegen options allow skipping the PLT.
|
|
|
|
pub fn non_lazy_bind(sess: &Session, llfn: &'ll Value) {
|
|
|
|
// Don't generate calls through PLT if it's not necessary
|
|
|
|
if !sess.needs_plt() {
|
|
|
|
Attribute::NonLazyBind.apply_llfn(Function, llfn);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-18 22:37:52 +00:00
|
|
|
pub(crate) fn default_optimisation_attrs(sess: &Session, llfn: &'ll Value) {
|
|
|
|
match sess.opts.optimize {
|
|
|
|
OptLevel::Size => {
|
|
|
|
llvm::Attribute::MinSize.unapply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeForSize.apply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeNone.unapply_llfn(Function, llfn);
|
2019-12-22 22:42:04 +00:00
|
|
|
}
|
2019-01-18 22:37:52 +00:00
|
|
|
OptLevel::SizeMin => {
|
|
|
|
llvm::Attribute::MinSize.apply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeForSize.apply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeNone.unapply_llfn(Function, llfn);
|
|
|
|
}
|
|
|
|
OptLevel::No => {
|
|
|
|
llvm::Attribute::MinSize.unapply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeForSize.unapply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeNone.unapply_llfn(Function, llfn);
|
|
|
|
}
|
|
|
|
_ => {}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-27 02:59:49 +00:00
|
|
|
/// Composite function which sets LLVM attributes for function depending on its AST (`#[attribute]`)
|
2016-05-27 17:27:56 +00:00
|
|
|
/// attributes.
|
2020-03-31 12:27:09 +00:00
|
|
|
pub fn from_fn_attrs(cx: &CodegenCx<'ll, 'tcx>, llfn: &'ll Value, instance: ty::Instance<'tcx>) {
|
2019-11-27 10:53:19 +00:00
|
|
|
let codegen_fn_attrs = cx.tcx.codegen_fn_attrs(instance.def_id());
|
2018-01-31 03:39:23 +00:00
|
|
|
|
2018-10-27 12:29:06 +00:00
|
|
|
match codegen_fn_attrs.optimize {
|
|
|
|
OptimizeAttr::None => {
|
2019-01-18 22:37:52 +00:00
|
|
|
default_optimisation_attrs(cx.tcx.sess, llfn);
|
2018-10-27 12:29:06 +00:00
|
|
|
}
|
|
|
|
OptimizeAttr::Speed => {
|
|
|
|
llvm::Attribute::MinSize.unapply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeForSize.unapply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeNone.unapply_llfn(Function, llfn);
|
|
|
|
}
|
|
|
|
OptimizeAttr::Size => {
|
|
|
|
llvm::Attribute::MinSize.apply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeForSize.apply_llfn(Function, llfn);
|
|
|
|
llvm::Attribute::OptimizeNone.unapply_llfn(Function, llfn);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-20 00:00:00 +00:00
|
|
|
let inline_attr = if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::NAKED) {
|
|
|
|
InlineAttr::Never
|
|
|
|
} else if codegen_fn_attrs.inline == InlineAttr::None && instance.def.requires_inline(cx.tcx) {
|
|
|
|
InlineAttr::Hint
|
|
|
|
} else {
|
|
|
|
codegen_fn_attrs.inline
|
|
|
|
};
|
|
|
|
inline(cx, llfn, inline_attr);
|
2018-11-18 18:51:56 +00:00
|
|
|
|
2018-08-16 20:19:04 +00:00
|
|
|
// The `uwtable` attribute according to LLVM is:
|
|
|
|
//
|
|
|
|
// This attribute indicates that the ABI being targeted requires that an
|
|
|
|
// unwind table entry be produced for this function even if we can show
|
|
|
|
// that no exceptions passes by it. This is normally the case for the
|
|
|
|
// ELF x86-64 abi, but it can be disabled for some compilation units.
|
|
|
|
//
|
|
|
|
// Typically when we're compiling with `-C panic=abort` (which implies this
|
|
|
|
// `no_landing_pads` check) we don't need `uwtable` because we can't
|
|
|
|
// generate any exceptions! On Windows, however, exceptions include other
|
|
|
|
// events such as illegal instructions, segfaults, etc. This means that on
|
|
|
|
// Windows we end up still needing the `uwtable` attribute even if the `-C
|
|
|
|
// panic=abort` flag is passed.
|
|
|
|
//
|
2020-07-07 15:12:44 +00:00
|
|
|
// You can also find more info on why Windows always requires uwtables here:
|
2018-08-16 20:19:04 +00:00
|
|
|
// https://bugzilla.mozilla.org/show_bug.cgi?id=1302078
|
Add Option to Force Unwind Tables
When panic != unwind, `nounwind` is added to all functions for a target.
This can cause issues when a panic happens with RUST_BACKTRACE=1, as
there needs to be a way to reconstruct the backtrace. There are three
possible sources of this information: forcing frame pointers (for which
an option exists already), debug info (for which an option exists), or
unwind tables.
Especially for embedded devices, forcing frame pointers can have code
size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads).
In code, it can be the case that debug info is not kept, so it is useful
to provide this third option, unwind tables, that users can use to
reconstruct the call stack. Reconstructing this stack is harder than
with frame pointers, but it is still possible.
This commit adds a compiler option which allows a user to force the
addition of unwind tables. Unwind tables cannot be disabled on targets
that require them for correctness, or when using `-C panic=unwind`.
2020-05-04 11:08:35 +00:00
|
|
|
if cx.sess().must_emit_unwind_tables() {
|
2018-08-16 20:19:04 +00:00
|
|
|
attributes::emit_uwtable(llfn, true);
|
|
|
|
}
|
|
|
|
|
2021-03-27 22:11:24 +00:00
|
|
|
// FIXME: none of these three functions interact with source level attributes.
|
2018-01-05 05:04:08 +00:00
|
|
|
set_frame_pointer_elimination(cx, llfn);
|
2018-12-30 19:59:03 +00:00
|
|
|
set_instrument_function(cx, llfn);
|
2018-01-05 05:04:08 +00:00
|
|
|
set_probestack(cx, llfn);
|
2018-01-05 21:26:26 +00:00
|
|
|
|
2018-05-08 13:10:16 +00:00
|
|
|
if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::COLD) {
|
2018-01-16 01:08:09 +00:00
|
|
|
Attribute::Cold.apply_llfn(Function, llfn);
|
|
|
|
}
|
2019-02-09 14:55:30 +00:00
|
|
|
if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::FFI_RETURNS_TWICE) {
|
|
|
|
Attribute::ReturnsTwice.apply_llfn(Function, llfn);
|
|
|
|
}
|
2020-04-13 22:19:46 +00:00
|
|
|
if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::FFI_PURE) {
|
|
|
|
Attribute::ReadOnly.apply_llfn(Function, llfn);
|
|
|
|
}
|
|
|
|
if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::FFI_CONST) {
|
|
|
|
Attribute::ReadNone.apply_llfn(Function, llfn);
|
|
|
|
}
|
2018-05-08 13:10:16 +00:00
|
|
|
if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::NAKED) {
|
2018-01-16 01:08:09 +00:00
|
|
|
naked(llfn, true);
|
|
|
|
}
|
2018-05-08 13:10:16 +00:00
|
|
|
if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::ALLOCATOR) {
|
2019-12-22 22:42:04 +00:00
|
|
|
Attribute::NoAlias.apply_llfn(llvm::AttributePlace::ReturnValue, llfn);
|
2018-01-16 01:08:09 +00:00
|
|
|
}
|
2020-09-28 20:10:38 +00:00
|
|
|
if codegen_fn_attrs.flags.contains(CodegenFnAttrFlags::CMSE_NONSECURE_ENTRY) {
|
2021-02-13 11:17:15 +00:00
|
|
|
llvm::AddFunctionAttrString(llfn, Function, cstr!("cmse_nonsecure_entry"));
|
2020-09-28 20:10:38 +00:00
|
|
|
}
|
2021-01-21 02:49:04 +00:00
|
|
|
if let Some(align) = codegen_fn_attrs.alignment {
|
|
|
|
llvm::set_alignment(llfn, align as usize);
|
|
|
|
}
|
2020-06-14 00:00:00 +00:00
|
|
|
sanitize(cx, codegen_fn_attrs.no_sanitize, llfn);
|
2018-05-24 19:03:05 +00:00
|
|
|
|
2018-08-02 16:10:26 +00:00
|
|
|
// Always annotate functions with the target-cpu they are compiled for.
|
|
|
|
// Without this, ThinLTO won't inline Rust functions into Clang generated
|
|
|
|
// functions (because Clang annotates functions this way too).
|
2018-12-07 18:51:03 +00:00
|
|
|
apply_target_cpu_attr(cx, llfn);
|
2020-09-17 09:39:26 +00:00
|
|
|
// tune-cpu is only conveyed through the attribute for our purpose.
|
|
|
|
// The target doesn't care; the subtarget reads our attribute.
|
|
|
|
apply_tune_cpu_attr(cx, llfn);
|
2018-08-02 16:10:26 +00:00
|
|
|
|
rustc: Add a new `wasm` ABI
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.
When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.
Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.
To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.
With the addition of a new ABI, this enables rustc to:
* Eventually remove the "wasm-bindgen compat hack". Once this
ABI is stable wasm-bindgen can switch to using it everywhere.
Afterwards the wasm32-unknown-unknown target can have its default ABI
updated to match C.
* Expose the ability to precisely match an ABI signature for a
WebAssembly function, regardless of what the C ABI that clang chooses
turns out to be.
* Continue to evolve the definition of the default C ABI to match what
clang does on all targets, since the purpose of that ABI will be
explicitly matching C rather than generating particular function
imports/exports.
Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
2021-04-01 23:08:29 +00:00
|
|
|
let mut function_features = codegen_fn_attrs
|
2021-03-13 13:29:39 +00:00
|
|
|
.target_features
|
|
|
|
.iter()
|
|
|
|
.map(|f| {
|
2019-12-22 22:42:04 +00:00
|
|
|
let feature = &f.as_str();
|
|
|
|
format!("+{}", llvm_util::to_llvm_feature(cx.tcx.sess, feature))
|
2021-03-13 13:29:39 +00:00
|
|
|
})
|
2020-10-08 22:23:27 +00:00
|
|
|
.chain(codegen_fn_attrs.instruction_set.iter().map(|x| match x {
|
|
|
|
InstructionSetAttr::ArmA32 => "-thumb-mode".to_string(),
|
|
|
|
InstructionSetAttr::ArmT32 => "+thumb-mode".to_string(),
|
|
|
|
}))
|
2021-03-13 13:29:39 +00:00
|
|
|
.collect::<Vec<String>>();
|
2018-02-10 22:28:17 +00:00
|
|
|
|
2020-12-30 18:52:21 +00:00
|
|
|
if cx.tcx.sess.target.is_like_wasm {
|
rustc: Add a new `wasm` ABI
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.
When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.
Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.
To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.
With the addition of a new ABI, this enables rustc to:
* Eventually remove the "wasm-bindgen compat hack". Once this
ABI is stable wasm-bindgen can switch to using it everywhere.
Afterwards the wasm32-unknown-unknown target can have its default ABI
updated to match C.
* Expose the ability to precisely match an ABI signature for a
WebAssembly function, regardless of what the C ABI that clang chooses
turns out to be.
* Continue to evolve the definition of the default C ABI to match what
clang does on all targets, since the purpose of that ABI will be
explicitly matching C rather than generating particular function
imports/exports.
Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
2021-04-01 23:08:29 +00:00
|
|
|
// If this function is an import from the environment but the wasm
|
|
|
|
// import has a specific module/name, apply them here.
|
2019-11-27 10:53:19 +00:00
|
|
|
if let Some(module) = wasm_import_module(cx.tcx, instance.def_id()) {
|
|
|
|
llvm::AddFunctionAttrStringValue(
|
|
|
|
llfn,
|
|
|
|
llvm::AttributePlace::Function,
|
2021-02-13 11:17:15 +00:00
|
|
|
cstr!("wasm-import-module"),
|
2019-11-27 10:53:19 +00:00
|
|
|
&module,
|
|
|
|
);
|
2019-12-16 22:15:57 +00:00
|
|
|
|
2019-12-22 22:42:04 +00:00
|
|
|
let name =
|
|
|
|
codegen_fn_attrs.link_name.unwrap_or_else(|| cx.tcx.item_name(instance.def_id()));
|
2019-12-16 22:15:57 +00:00
|
|
|
let name = CString::new(&name.as_str()[..]).unwrap();
|
|
|
|
llvm::AddFunctionAttrStringValue(
|
|
|
|
llfn,
|
|
|
|
llvm::AttributePlace::Function,
|
2021-02-13 11:17:15 +00:00
|
|
|
cstr!("wasm-import-name"),
|
2019-12-16 22:15:57 +00:00
|
|
|
&name,
|
|
|
|
);
|
2018-02-10 22:28:17 +00:00
|
|
|
}
|
rustc: Add a new `wasm` ABI
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.
When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.
Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.
To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.
With the addition of a new ABI, this enables rustc to:
* Eventually remove the "wasm-bindgen compat hack". Once this
ABI is stable wasm-bindgen can switch to using it everywhere.
Afterwards the wasm32-unknown-unknown target can have its default ABI
updated to match C.
* Expose the ability to precisely match an ABI signature for a
WebAssembly function, regardless of what the C ABI that clang chooses
turns out to be.
* Continue to evolve the definition of the default C ABI to match what
clang does on all targets, since the purpose of that ABI will be
explicitly matching C rather than generating particular function
imports/exports.
Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
2021-04-01 23:08:29 +00:00
|
|
|
|
|
|
|
// The `"wasm"` abi on wasm targets automatically enables the
|
|
|
|
// `+multivalue` feature because the purpose of the wasm abi is to match
|
|
|
|
// the WebAssembly specification, which has this feature. This won't be
|
|
|
|
// needed when LLVM enables this `multivalue` feature by default.
|
|
|
|
if !cx.tcx.is_closure(instance.def_id()) {
|
|
|
|
let abi = cx.tcx.fn_sig(instance.def_id()).abi();
|
|
|
|
if abi == Abi::Wasm {
|
|
|
|
function_features.push("+multivalue".to_string());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if !function_features.is_empty() {
|
|
|
|
let mut global_features = llvm_util::llvm_global_features(cx.tcx.sess);
|
|
|
|
global_features.extend(function_features.into_iter());
|
|
|
|
let features = global_features.join(",");
|
|
|
|
let val = CString::new(features).unwrap();
|
|
|
|
llvm::AddFunctionAttrStringValue(
|
|
|
|
llfn,
|
|
|
|
llvm::AttributePlace::Function,
|
|
|
|
cstr!("target-features"),
|
|
|
|
&val,
|
|
|
|
);
|
2018-02-10 22:28:17 +00:00
|
|
|
}
|
2016-11-30 00:02:00 +00:00
|
|
|
}
|
|
|
|
|
2019-06-13 21:48:52 +00:00
|
|
|
fn wasm_import_module(tcx: TyCtxt<'_>, id: DefId) -> Option<CString> {
|
2019-12-22 22:42:04 +00:00
|
|
|
tcx.wasm_import_module_map(id.krate).get(&id).map(|s| CString::new(&s[..]).unwrap())
|
2018-02-10 22:28:17 +00:00
|
|
|
}
|