mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ced5e04e8b
rust/src/test/codegen/function-arguments.rs

148 lines
4.1 KiB
Rust
Raw Normal View History

Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
// Copyright 2015 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.
// compile-flags: -C no-prepopulate-passes
rustc_trans: always insert alignment padding, even before the first field.
2017-06-25 04:42:55 -05:00
// ignore-tidy-linelength
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
Avoid loading the whole gdb debug scripts section. This is so LLVM isn't forced to load every byte of it. Also sets the alignment of the load. Adds a test for the debug script section.
2015-09-15 16:22:16 -05:00
#![crate_type = "lib"]
rustc: Implement the #[global_allocator] attribute This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-03 16:54:08 -05:00
#![feature(custom_attribute)]
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
pub struct S {
_field: [i64; 4],
}
pub struct UnsafeInner {
_field: std::cell::UnsafeCell<i16>,
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: zeroext i1 @boolean(i1 zeroext %x)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
#[no_mangle]
pub fn boolean(x: bool) -> bool {
x
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: @readonly_borrow(i32* noalias readonly dereferenceable(4) %arg0)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
// FIXME #25759 This should also have `nocapture`
#[no_mangle]
pub fn readonly_borrow(_: &i32) {
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: @static_borrow(i32* noalias readonly dereferenceable(4) %arg0)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
// static borrow may be captured
#[no_mangle]
pub fn static_borrow(_: &'static i32) {
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: @named_borrow(i32* noalias readonly dereferenceable(4) %arg0)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
// borrow with named lifetime may be captured
#[no_mangle]
pub fn named_borrow<'r>(_: &'r i32) {
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: @unsafe_borrow(%UnsafeInner* dereferenceable(2) %arg0)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
// unsafe interior means this isn't actually readonly and there may be aliases ...
#[no_mangle]
pub fn unsafe_borrow(_: &UnsafeInner) {
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: @mutable_unsafe_borrow(%UnsafeInner* dereferenceable(2) %arg0)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
// ... unless this is a mutable borrow, those never alias
Workaround LLVM optimizer bug by not marking &mut pointers as noalias LLVM's memory dependence analysis doesn't properly account for calls that could unwind and thus effectively act as a branching point. This can lead to stores that are only visible when the call unwinds being removed, possibly leading to calls to drop() functions with b0rked memory contents. As there is no fix for this in LLVM yet and we want to keep compatibility to current LLVM versions anyways, we have to workaround this bug by omitting the noalias attribute on &mut function arguments. Benchmarks suggest that the performance loss by this change is very small. Thanks to @RalfJung for pushing me towards not removing too many noalias annotations and @alexcrichton for helping out with the test for this bug. Fixes #29485
2016-01-29 04:11:24 -06:00
// ... except that there's this LLVM bug that forces us to not use noalias, see #29485
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
#[no_mangle]
pub fn mutable_unsafe_borrow(_: &mut UnsafeInner) {
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: @mutable_borrow(i32* dereferenceable(4) %arg0)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
// FIXME #25759 This should also have `nocapture`
Workaround LLVM optimizer bug by not marking &mut pointers as noalias LLVM's memory dependence analysis doesn't properly account for calls that could unwind and thus effectively act as a branching point. This can lead to stores that are only visible when the call unwinds being removed, possibly leading to calls to drop() functions with b0rked memory contents. As there is no fix for this in LLVM yet and we want to keep compatibility to current LLVM versions anyways, we have to workaround this bug by omitting the noalias attribute on &mut function arguments. Benchmarks suggest that the performance loss by this change is very small. Thanks to @RalfJung for pushing me towards not removing too many noalias annotations and @alexcrichton for helping out with the test for this bug. Fixes #29485
2016-01-29 04:11:24 -06:00
// ... there's this LLVM bug that forces us to not use noalias, see #29485
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
#[no_mangle]
pub fn mutable_borrow(_: &mut i32) {
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: @indirect_struct(%S* noalias nocapture dereferenceable(32) %arg0)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
#[no_mangle]
pub fn indirect_struct(_: S) {
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: @borrowed_struct(%S* noalias readonly dereferenceable(32) %arg0)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
// FIXME #25759 This should also have `nocapture`
#[no_mangle]
pub fn borrowed_struct(_: &S) {
}
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: noalias dereferenceable(4) i32* @_box(i32* noalias dereferenceable(4) %x)
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
#[no_mangle]
pub fn _box(x: Box<i32>) -> Box<i32> {
x
}
// CHECK: @struct_return(%S* noalias nocapture sret dereferenceable(32))
#[no_mangle]
pub fn struct_return() -> S {
S {
_field: [0, 0, 0, 0]
}
}
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
// Hack to get the correct size for the length part in slices
Avoid unnecessary copies of arguments that are simple bindings Initially MIR differentiated between arguments and locals, which introduced a need to add extra copies assigning the argument to a local, even for simple bindings. This differentiation no longer exists, but we're still creating those copies, bloating the MIR and LLVM IR we emit. Additionally, the current approach means that we create debug info for both the incoming argument (marking it as an argument), and then immediately shadow it a local that goes by the same name. This can be confusing when using e.g. "info args" in gdb, or when e.g. a debugger with a GUI displays the function arguments separately from the local variables, especially when the binding is mutable, because the argument doesn't change, while the local variable does.
2017-10-11 13:49:36 -05:00
// CHECK: @helper([[USIZE:i[0-9]+]] %arg0)
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
#[no_mangle]
Update codegen tests.
2017-10-30 12:18:00 -05:00
pub fn helper(_: usize) {
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
}
rustc_trans: go through layouts uniformly for fat pointers and variants.
2017-09-21 12:40:50 -05:00
// CHECK: @slice([0 x i8]* noalias nonnull readonly %arg0.0, [[USIZE]] %arg0.1)
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
// FIXME #25759 This should also have `nocapture`
#[no_mangle]
Update codegen tests.
2017-10-30 12:18:00 -05:00
pub fn slice(_: &[u8]) {
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
}
rustc_trans: go through layouts uniformly for fat pointers and variants.
2017-09-21 12:40:50 -05:00
// CHECK: @mutable_slice([0 x i8]* nonnull %arg0.0, [[USIZE]] %arg0.1)
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
// FIXME #25759 This should also have `nocapture`
Workaround LLVM optimizer bug by not marking &mut pointers as noalias LLVM's memory dependence analysis doesn't properly account for calls that could unwind and thus effectively act as a branching point. This can lead to stores that are only visible when the call unwinds being removed, possibly leading to calls to drop() functions with b0rked memory contents. As there is no fix for this in LLVM yet and we want to keep compatibility to current LLVM versions anyways, we have to workaround this bug by omitting the noalias attribute on &mut function arguments. Benchmarks suggest that the performance loss by this change is very small. Thanks to @RalfJung for pushing me towards not removing too many noalias annotations and @alexcrichton for helping out with the test for this bug. Fixes #29485
2016-01-29 04:11:24 -06:00
// ... there's this LLVM bug that forces us to not use noalias, see #29485
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
#[no_mangle]
Update codegen tests.
2017-10-30 12:18:00 -05:00
pub fn mutable_slice(_: &mut [u8]) {
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
}
rustc_trans: go through layouts uniformly for fat pointers and variants.
2017-09-21 12:40:50 -05:00
// CHECK: @unsafe_slice([0 x %UnsafeInner]* nonnull %arg0.0, [[USIZE]] %arg0.1)
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
// unsafe interior means this isn't actually readonly and there may be aliases ...
#[no_mangle]
pub fn unsafe_slice(_: &[UnsafeInner]) {
}
rustc_trans: go through layouts uniformly for fat pointers and variants.
2017-09-21 12:40:50 -05:00
// CHECK: @str([0 x i8]* noalias nonnull readonly %arg0.0, [[USIZE]] %arg0.1)
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
// FIXME #25759 This should also have `nocapture`
#[no_mangle]
Update codegen tests.
2017-10-30 12:18:00 -05:00
pub fn str(_: &[u8]) {
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
}
rustc_trans: go through layouts uniformly for fat pointers and variants.
2017-09-21 12:40:50 -05:00
// CHECK: @trait_borrow(%"core::ops::drop::Drop"* nonnull %arg0.0, {}* noalias nonnull readonly %arg0.1)
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
// FIXME #25759 This should also have `nocapture`
#[no_mangle]
Update codegen tests.
2017-10-30 12:18:00 -05:00
pub fn trait_borrow(_: &Drop) {
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
}
rustc_trans: go through layouts uniformly for fat pointers and variants.
2017-09-21 12:40:50 -05:00
// CHECK: @trait_box(%"core::ops::drop::Drop"* noalias nonnull, {}* noalias nonnull readonly)
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
#[no_mangle]
Update codegen tests.
2017-10-30 12:18:00 -05:00
pub fn trait_box(_: Box<Drop>) {
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
}
rustc_trans: go through layouts uniformly for fat pointers and variants.
2017-09-21 12:40:50 -05:00
// CHECK: { [0 x i8], [0 x i16]*, [0 x i8], [[USIZE]], [0 x i8] } @return_slice([0 x i16]* noalias nonnull readonly %x.0, [[USIZE]] %x.1)
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
#[no_mangle]
Update codegen tests.
2017-10-30 12:18:00 -05:00
pub fn return_slice(x: &[u16]) -> &[u16] {
Pass fat pointers in two immediate arguments This has a number of advantages compared to creating a copy in memory and passing a pointer. The obvious one is that we don't have to put the data into memory but can keep it in registers. Since we're currently passing a pointer anyway (instead of using e.g. a known offset on the stack, which is what the `byval` attribute would achieve), we only use a single additional register for each fat pointer, but save at least two pointers worth of stack in exchange (sometimes more because more than one copy gets eliminated). On archs that pass arguments on the stack, we save a pointer worth of stack even without considering the omitted copies. Additionally, LLVM can optimize the code a lot better, to a large degree due to the fact that lots of copies are gone or can be optimized away. Additionally, we can now emit attributes like nonnull on the data and/or vtable pointers contained in the fat pointer, potentially allowing for even more optimizations. This results in LLVM passes being about 3-7% faster (depending on the crate), and the resulting code is also a few percent smaller, for example: text data filename 5671479 3941461 before/librustc-d8ace771.so 5447663 3905745 after/librustc-d8ace771.so 1944425 2394024 before/libstd-d8ace771.so 1896769 2387610 after/libstd-d8ace771.so I had to remove a call in the backtrace-debuginfo test, because LLVM can now merge the tails of some blocks when optimizations are turned on, which can't correctly preserve line info. Fixes #22924 Cc #22891 (at least for fat pointers the code is good now)
2015-06-18 16:57:40 -05:00
x
}
Revamp codegen tests to check IR quality instead of quantity The current codegen tests only compare IR line counts between similar rust and C programs, the latter getting compiled with clang. That looked like a good idea back then, but actually things like lifetime intrinsics mean that less IR isn't always better, so the metric isn't really helpful. Instead, we can start doing tests that check specific aspects of the generated IR, like attributes or metadata. To do that, we can use LLVM's FileCheck tool which has a number of useful features for such tests. To start off, I created some tests for a few things that were recently added and/or broken.
2015-05-24 11:07:52 -05:00
// CHECK: noalias i8* @allocator()
#[no_mangle]
#[allocator]
pub fn allocator() -> *const i8 {
std::ptr::null()
}
Reference in New Issue Copy Permalink