Diff of own seperate fail!(fmt!(...)) -> fail!(...) and fail!(~"...") -> fail!("...") cleanup #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… -> fail!("...") cleanup
|
Merged with an adjusted commit message |
dotdash
pushed a commit
that referenced
this pull request
May 14, 2013
Doc review, as requested :-).
dotdash
pushed a commit
that referenced
this pull request
May 30, 2013
Passing higher alignment values gives the optimization passes more freedom since it can copy in larger chunks. This change results in rustc outputting the same post-optimization IR as clang for swaps and most copies excluding the lack of information about padding.
Code snippet:
```rust
#[inline(never)]
fn swap<T>(x: &mut T, y: &mut T) {
util::swap(x, y);
}
```
Original IR (for `int`):
```llvm
define internal fastcc void @_ZN9swap_283417_a71830ca3ed2d65d3_00E(i64*, i64*) #1 {
static_allocas:
%2 = icmp eq i64* %0, %1
br i1 %2, label %_ZN4util9swap_283717_a71830ca3ed2d65d3_00E.exit, label %3
; <label>:3 ; preds = %static_allocas
%4 = load i64* %0, align 1
%5 = load i64* %1, align 1
store i64 %5, i64* %0, align 1
store i64 %4, i64* %1, align 1
br label %_ZN4util9swap_283717_a71830ca3ed2d65d3_00E.exit
_ZN4util9swap_283717_a71830ca3ed2d65d3_00E.exit: ; preds = %3, %static_allocas
ret void
}
```
After rust-lang#6710:
```llvm
define internal fastcc void @_ZN9swap_283017_a71830ca3ed2d65d3_00E(i64* nocapture, i64* nocapture) #1 {
static_allocas:
%2 = load i64* %0, align 1
%3 = load i64* %1, align 1
store i64 %3, i64* %0, align 1
store i64 %2, i64* %1, align 1
ret void
}
```
After this change:
```llvm
define internal fastcc void @_ZN9swap_283017_a71830ca3ed2d65d3_00E(i64* nocapture, i64* nocapture) #1 {
static_allocas:
%2 = load i64* %0, align 8
%3 = load i64* %1, align 8
store i64 %3, i64* %0, align 8
store i64 %2, i64* %1, align 8
ret void
}
```
Another example:
```rust
#[inline(never)]
fn set<T>(x: &mut T, y: T) {
*x = y;
}
```
Before, with `(int, int)` (align 1):
```llvm
define internal fastcc void @_ZN8set_282517_8fa972e3f9e451983_00E({ i64, i64 }* nocapture, { i64, i64 }* nocapture) #1 {
static_allocas:
%2 = bitcast { i64, i64 }* %1 to i8*
%3 = bitcast { i64, i64 }* %0 to i8*
tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 16, i32 1, i1 false)
ret void
}
```
After, with `(int, int)` (align 8):
```llvm
define internal fastcc void @_ZN8set_282617_8fa972e3f9e451983_00E({ i64, i64 }* nocapture, { i64, i64 }* nocapture) #1 {
static_allocas:
%2 = bitcast { i64, i64 }* %1 to i8*
%3 = bitcast { i64, i64 }* %0 to i8*
tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 16, i32 8, i1 false)
ret void
}
```
dotdash
pushed a commit
that referenced
this pull request
Aug 9, 2013
This allows LLVM to optimize vector iterators to an `getelementptr` and
`icmp` pair, instead of `getelementptr` and *two* comparisons.
Code snippet:
~~~
fn foo(xs: &mut [f64]) {
for x in xs.mut_iter() {
*x += 10.0;
}
}
~~~
LLVM IR at stage0:
~~~
; Function Attrs: noinline uwtable
define void @"_ZN3foo17_68e1b25bca131dba7_0$x2e0E"({ i64, %tydesc*, i8*, i8*, i8 }* nocapture, { double*, i64 }* nocapture) #1 {
"function top level":
%2 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 0
%3 = load double** %2, align 8
%4 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 1
%5 = load i64* %4, align 8
%6 = ptrtoint double* %3 to i64
%7 = and i64 %5, -8
%8 = add i64 %7, %6
%9 = inttoptr i64 %8 to double*
%10 = icmp eq double* %3, %9
%11 = icmp eq double* %3, null
%or.cond6 = or i1 %10, %11
br i1 %or.cond6, label %match_case, label %match_else
match_else: ; preds = %"function top level", %match_else
%12 = phi double* [ %13, %match_else ], [ %3, %"function top level" ]
%13 = getelementptr double* %12, i64 1
%14 = load double* %12, align 8
%15 = fadd double %14, 1.000000e+01
store double %15, double* %12, align 8
%16 = icmp eq double* %13, %9
%17 = icmp eq double* %13, null
%or.cond = or i1 %16, %17
br i1 %or.cond, label %match_case, label %match_else
match_case: ; preds = %match_else, %"function top level"
ret void
}
~~~
Optimized LLVM IR at stage1/stage2:
~~~
; Function Attrs: noinline uwtable
define void @"_ZN3foo17_68e1b25bca131dba7_0$x2e0E"({ i64, %tydesc*, i8*, i8*, i8 }* nocapture, { double*, i64 }* nocapture) #1 {
"function top level":
%2 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 0
%3 = load double** %2, align 8
%4 = getelementptr inbounds { double*, i64 }* %1, i64 0, i32 1
%5 = load i64* %4, align 8
%6 = lshr i64 %5, 3
%7 = getelementptr inbounds double* %3, i64 %6
%8 = icmp eq i64 %6, 0
%9 = icmp eq double* %3, null
%or.cond6 = or i1 %8, %9
br i1 %or.cond6, label %match_case, label %match_else
match_else: ; preds = %"function top level", %match_else
%.sroa.0.0.in7 = phi double* [ %10, %match_else ], [ %3, %"function top level" ]
%10 = getelementptr inbounds double* %.sroa.0.0.in7, i64 1
%11 = load double* %.sroa.0.0.in7, align 8
%12 = fadd double %11, 1.000000e+01
store double %12, double* %.sroa.0.0.in7, align 8
%13 = icmp eq double* %10, %7
br i1 %13, label %match_case, label %match_else
match_case: ; preds = %match_else, %"function top level"
ret void
}
~~~
dotdash
pushed a commit
that referenced
this pull request
Jan 14, 2014
This brings Rust in line with how `clang` handles return pointers.
Example:
pub fn bar() -> [uint, .. 8] {
let a = [0, .. 8];
a
}
Before:
; Function Attrs: nounwind uwtable
define void @_ZN3bar17ha4635c6f704bfa334v0.0E([8 x i64]* nocapture, { i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #1 {
"function top level":
%a = alloca [8 x i64], align 8
%2 = bitcast [8 x i64]* %a to i8*
call void @llvm.memset.p0i8.i64(i8* %2, i8 0, i64 64, i32 8, i1 false)
%3 = bitcast [8 x i64]* %0 to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 64, i32 8, i1 false)
ret void
}
After:
; Function Attrs: nounwind uwtable
define void @_ZN3bar17ha4635c6f704bfa334v0.0E([8 x i64]* noalias nocapture sret, { i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #1 {
"function top level":
%2 = bitcast [8 x i64]* %0 to i8*
call void @llvm.memset.p0i8.i64(i8* %2, i8 0, i64 64, i32 8, i1 false)
ret void
}
Closes rust-lang#9072
Closes rust-lang#7298
Closes rust-lang#9154
dotdash
pushed a commit
that referenced
this pull request
Jan 14, 2014
C-like enums are excluded from this for now, because the code paths
specific to them need to be changed.
fn foo() -> Option<~int> { Some(~5) }
Before:
; Function Attrs: uwtable
define void @_ZN3foo18hdec6e36682b87eeaf4v0.0E(%"enum.std::option::Option<~int>[#1]"* noalias nocapture sret, { i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #0 {
"function top level":
%2 = tail call %"enum.std::libc::types::common::c95::c_void[#1]"* @"_ZN2rt11global_heap10malloc_raw17h56c543b77f9b78aY11v0.9$x2dpreE"({ i64, %tydesc*, i8*, i8*, i8 }* undef, i64 8)
%3 = bitcast %"enum.std::libc::types::common::c95::c_void[#1]"* %2 to i64*
store i64 5, i64* %3, align 8
%4 = getelementptr inbounds %"enum.std::option::Option<~int>[#1]"* %0, i64 0, i32 0
store i64* %3, i64** %4, align 8
ret void
}
After:
; Function Attrs: uwtable
define %"enum.std::option::Option<~int>[#1]" @_ZN3foo18h2cbf6557a3143edah4v0.0E({ i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #0 {
"function top level":
%1 = tail call %"enum.std::libc::types::common::c95::c_void[#1]"* @"_ZN2rt11global_heap10malloc_raw18hb1e9dd1beab35edau11v0.9$x2dpreE"({ i64, %tydesc*, i8*, i8*, i8 }* undef, i64 8)
%2 = bitcast %"enum.std::libc::types::common::c95::c_void[#1]"* %1 to i64*
store i64 5, i64* %2, align 8
%oldret = insertvalue %"enum.std::option::Option<~int>[#1]" undef, i64* %2, 0
ret %"enum.std::option::Option<~int>[#1]" %oldret
}
dotdash
pushed a commit
that referenced
this pull request
Jan 14, 2014
C-like enums are excluded from this for now, because the code paths
specific to them need to be changed.
fn foo() -> Option<~int> { Some(~5) }
Before:
; Function Attrs: uwtable
define void @_ZN3foo18hdec6e36682b87eeaf4v0.0E(%"enum.std::option::Option<~int>[#1]"* noalias nocapture sret, { i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #0 {
"function top level":
%2 = tail call %"enum.std::libc::types::common::c95::c_void[#1]"* @"_ZN2rt11global_heap10malloc_raw17h56c543b77f9b78aY11v0.9$x2dpreE"({ i64, %tydesc*, i8*, i8*, i8 }* undef, i64 8)
%3 = bitcast %"enum.std::libc::types::common::c95::c_void[#1]"* %2 to i64*
store i64 5, i64* %3, align 8
%4 = getelementptr inbounds %"enum.std::option::Option<~int>[#1]"* %0, i64 0, i32 0
store i64* %3, i64** %4, align 8
ret void
}
After:
; Function Attrs: uwtable
define %"enum.std::option::Option<~int>[#1]" @_ZN3foo18h2cbf6557a3143edah4v0.0E({ i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #0 {
"function top level":
%1 = tail call %"enum.std::libc::types::common::c95::c_void[#1]"* @"_ZN2rt11global_heap10malloc_raw18hb1e9dd1beab35edau11v0.9$x2dpreE"({ i64, %tydesc*, i8*, i8*, i8 }* undef, i64 8)
%2 = bitcast %"enum.std::libc::types::common::c95::c_void[#1]"* %1 to i64*
store i64 5, i64* %2, align 8
%oldret = insertvalue %"enum.std::option::Option<~int>[#1]" undef, i64* %2, 0
ret %"enum.std::option::Option<~int>[#1]" %oldret
}
dotdash
pushed a commit
that referenced
this pull request
Jan 14, 2014
Example:
void ({ i64, %tydesc*, i8*, i8*, i8 }*, i64*, %"struct.std::fmt::Formatter[#1]"*)*
Before, we would print 20 levels deep due to recursion in the type
definition.
dotdash
pushed a commit
that referenced
this pull request
Jan 14, 2014
Example:
void ({ i64, %tydesc*, i8*, i8*, i8 }*, i64*, %"struct.std::fmt::Formatter[#1]"*)*
Before, we would print 20 levels deep due to recursion in the type
definition.
dotdash
added a commit
that referenced
this pull request
Feb 15, 2014
Function parameters that are to be passed by value but don't fit into a
single register are currently passed by creating a copy on the stack and
passing a pointer to that copy to the callee. Since the copy is made
just for the function call, there are no aliases.
For example, this sometimes allows LLVM to eliminate unnecessary calls
to drop glue. Given
````rust
struct Foo {
a: int,
b: Option<~str>,
}
extern {
fn eat(eat: Option<~str>);
}
pub fn foo(v: Foo) {
match v {
Foo { a: _, b } => unsafe { eat(b) }
}
}
````
LLVM currently can't eliminate the drop call for the string, because it
only sees a _pointer_ to Foo, for which it has to expect an alias. So we
get:
````llvm
; Function Attrs: uwtable
define void @_ZN3foo20h9f32c90ae7201edbxaa4v0.0E(%struct.Foo* nocapture) unnamed_addr #0 {
"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit":
%1 = getelementptr inbounds %struct.Foo* %0, i64 0, i32 1, i32 0
%2 = load { i64, i64, [0 x i8] }** %1, align 8
store { i64, i64, [0 x i8] }* null, { i64, i64, [0 x i8] }** %1, align 8
%3 = ptrtoint { i64, i64, [0 x i8] }* %2 to i64
%.fca.0.insert = insertvalue { i64 } undef, i64 %3, 0
tail call void @eat({ i64 } %.fca.0.insert)
%4 = load { i64, i64, [0 x i8] }** %1, align 8
%5 = icmp eq { i64, i64, [0 x i8] }* %4, null
br i1 %5, label %_ZN3Foo9glue_drop17hf611996539d3036fE.exit, label %"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i"
"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i": ; preds = %"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit"
%6 = bitcast { i64, i64, [0 x i8] }* %4 to i8*
tail call void @free(i8* %6) #1
br label %_ZN3Foo9glue_drop17hf611996539d3036fE.exit
_ZN3Foo9glue_drop17hf611996539d3036fE.exit: ; preds = %"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit", %"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i"
ret void
}
````
But with the `noalias` attribute, it can safely optimize that to:
````llvm
define void @_ZN3foo20hd28431f929f0d6c4xaa4v0.0E(%struct.Foo* noalias nocapture) unnamed_addr #0 {
_ZN3Foo9glue_drop17he9afbc09d4e9c851E.exit:
%1 = getelementptr inbounds %struct.Foo* %0, i64 0, i32 1, i32 0
%2 = load { i64, i64, [0 x i8] }** %1, align 8
store { i64, i64, [0 x i8] }* null, { i64, i64, [0 x i8] }** %1, align 8
%3 = ptrtoint { i64, i64, [0 x i8] }* %2 to i64
%.fca.0.insert = insertvalue { i64 } undef, i64 %3, 0
tail call void @eat({ i64 } %.fca.0.insert)
ret void
}
````
dotdash
pushed a commit
that referenced
this pull request
Feb 23, 2014
Function parameters that are to be passed by value but don't fit into a
single register are currently passed by creating a copy on the stack and
passing a pointer to that copy to the callee. Since the copy is made
just for the function call, there are no aliases.
For example, this sometimes allows LLVM to eliminate unnecessary calls
to drop glue. Given
````rust
struct Foo {
a: int,
b: Option<~str>,
}
extern {
fn eat(eat: Option<~str>);
}
pub fn foo(v: Foo) {
match v {
Foo { a: _, b } => unsafe { eat(b) }
}
}
````
LLVM currently can't eliminate the drop call for the string, because it
only sees a _pointer_ to Foo, for which it has to expect an alias. So we
get:
````llvm
; Function Attrs: uwtable
define void @_ZN3foo20h9f32c90ae7201edbxaa4v0.0E(%struct.Foo* nocapture) unnamed_addr #0 {
"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit":
%1 = getelementptr inbounds %struct.Foo* %0, i64 0, i32 1, i32 0
%2 = load { i64, i64, [0 x i8] }** %1, align 8
store { i64, i64, [0 x i8] }* null, { i64, i64, [0 x i8] }** %1, align 8
%3 = ptrtoint { i64, i64, [0 x i8] }* %2 to i64
%.fca.0.insert = insertvalue { i64 } undef, i64 %3, 0
tail call void @eat({ i64 } %.fca.0.insert)
%4 = load { i64, i64, [0 x i8] }** %1, align 8
%5 = icmp eq { i64, i64, [0 x i8] }* %4, null
br i1 %5, label %_ZN3Foo9glue_drop17hf611996539d3036fE.exit, label %"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i"
"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i": ; preds = %"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit"
%6 = bitcast { i64, i64, [0 x i8] }* %4 to i8*
tail call void @free(i8* %6) #1
br label %_ZN3Foo9glue_drop17hf611996539d3036fE.exit
_ZN3Foo9glue_drop17hf611996539d3036fE.exit: ; preds = %"_ZN34std..option..Option$LT$$UP$str$GT$9glue_drop17hc39b3015f3b9c69dE.exit", %"_ZN8_$UP$str9glue_drop17h15dbdbe2b8897a98E.exit.i.i"
ret void
}
````
But with the `noalias` attribute, it can safely optimize that to:
````llvm
define void @_ZN3foo20hd28431f929f0d6c4xaa4v0.0E(%struct.Foo* noalias nocapture) unnamed_addr #0 {
_ZN3Foo9glue_drop17he9afbc09d4e9c851E.exit:
%1 = getelementptr inbounds %struct.Foo* %0, i64 0, i32 1, i32 0
%2 = load { i64, i64, [0 x i8] }** %1, align 8
store { i64, i64, [0 x i8] }* null, { i64, i64, [0 x i8] }** %1, align 8
%3 = ptrtoint { i64, i64, [0 x i8] }* %2 to i64
%.fca.0.insert = insertvalue { i64 } undef, i64 %3, 0
tail call void @eat({ i64 } %.fca.0.insert)
ret void
}
````
dotdash
pushed a commit
that referenced
this pull request
May 31, 2014
This includes a change to the way lifetime names are generated. Say we
figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead
of just generating a new lifetime `'c` like before to replace them, we
would reuse `'a`. This is done so that when the lifetime name comes
from an impl, we don't give something that's completely off, and we
don't have to do much work to figure out where the name came from. For
example, for the following code snippet:
```rust
struct Baz<'x> {
bar: &'x int
}
impl<'x> Baz<'x> {
fn baz1(&self) -> &int {
self.bar
}
}
```
`[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`)
have to be marked the same lifetime. With the old method, we would
generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int`
or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.
dotdash
pushed a commit
that referenced
this pull request
May 31, 2014
…d, r=nmatsakis
This includes a change to the way lifetime names are generated. Say we
figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead
of just generating a new lifetime `'c` like before to replace them, we
would reuse `'a`. This is done so that when the lifetime name comes
from an impl, we don't give something that's completely off, and we
don't have to do much work to figure out where the name came from. For
example, for the following code snippet:
```rust
struct Baz<'x> {
bar: &'x int
}
impl<'x> Baz<'x> {
fn baz1(&self) -> &int {
self.bar
}
}
```
`[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`)
have to be marked the same lifetime. With the old method, we would
generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int`
or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.
dotdash
pushed a commit
that referenced
this pull request
May 31, 2014
Suggested revisions to PR 13676.
dotdash
pushed a commit
that referenced
this pull request
Jul 4, 2014
```Rust
struct With {
x: int,
f: NoCopy
}
#[no_mangle]
fn bar() {
let mine = With { x: 3, f: NoCopy };
match mine {
c => {
foo(c);
}
}
}
#[no_mangle]
fn foo(_: With) {}
```
Before:
```LLVM
define internal void @bar() unnamed_addr #1 {
entry-block:
%mine = alloca %"struct.With<[]>"
%__llmatch = alloca %"struct.With<[]>"*
%c = alloca %"struct.With<[]>"
%0 = getelementptr inbounds %"struct.With<[]>"* %mine, i32 0, i32 0
store i64 3, i64* %0
%1 = getelementptr inbounds %"struct.With<[]>"* %mine, i32 0, i32 1
store %"struct.With<[]>"* %mine, %"struct.With<[]>"** %__llmatch
br label %case_body
case_body: ; preds = %entry-block
%2 = load %"struct.With<[]>"** %__llmatch
%3 = bitcast %"struct.With<[]>"* %2 to i8*
%4 = bitcast %"struct.With<[]>"* %c to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %4, i8* %3, i64 8, i32 8, i1 false)
%5 = load %"struct.With<[]>"* %c
call void @foo(%"struct.With<[]>" %5)
br label %join
join: ; preds = %case_body
ret void
}
```
After:
```LLVM
define internal void @bar() unnamed_addr #1 {
entry-block:
%mine = alloca %"struct.With<[]>"
%c = alloca %"struct.With<[]>"*
%0 = getelementptr inbounds %"struct.With<[]>"* %mine, i32 0, i32 0
store i64 3, i64* %0
%1 = getelementptr inbounds %"struct.With<[]>"* %mine, i32 0, i32 1
store %"struct.With<[]>"* %mine, %"struct.With<[]>"** %c
br label %case_body
case_body: ; preds = %entry-block
%2 = load %"struct.With<[]>"** %c
%3 = load %"struct.With<[]>"* %2
call void @foo(%"struct.With<[]>" %3)
br label %join
join: ; preds = %case_body
ret void
}
```
r? @pcwalton
dotdash
pushed a commit
that referenced
this pull request
Dec 2, 2015
…hange Change verbiage in Stack & Heap page
dotdash
pushed a commit
that referenced
this pull request
Feb 27, 2016
suggest: Put the `use` in suggested code inside the quotes
Change import a trait suggestion from:
help: candidate #1: use `std::io::Write`
to
help: candidate #1: `use std::io::Write`
so that the code can be copied directly.
Fixes rust-lang#31864
dotdash
pushed a commit
that referenced
this pull request
Oct 11, 2017
…crichton Allow atomic operations up to 32 bits The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides [user space helpers] which can be used to perform atomic operations. When linked with `libgcc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics. [user space helpers]: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt 32-bit versions of these kernel level helpers were introduced in Linux Kernel 2.6.12, and 64-bit version of these kernel level helpers were introduced in Linux Kernel 3.1. I have selected 32 bit versions as std currently only requires Linux version 2.6.18 and above as far as I am aware. As this target is specifically linux and gnueabi, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all. I have used this change in a custom target (along with xargo) to build std, as well as a number of higher level crates. ## Additional information For reference, here is what a a code snippet decompiles to: ```rust use std::sync::atomic::{AtomicIsize, Ordering}; #[no_mangle] pub extern fn foo(a: &AtomicIsize) -> isize { a.fetch_add(1, Ordering::SeqCst) } ``` ``` Disassembly of section .text.foo: 00000000 <foo>: 0: e92d4800 push {fp, lr} 4: e3a01001 mov r1, #1 8: ebfffffe bl 0 <__sync_fetch_and_add_4> c: e8bd8800 pop {fp, pc} ``` Which in turn is provided by `libgcc.a`, which has code which looks like this: ``` Disassembly of section .text: 00000000 <__sync_fetch_and_add_4>: 0: e92d40f8 push {r3, r4, r5, r6, r7, lr} 4: e1a05000 mov r5, r0 8: e1a07001 mov r7, r1 c: e59f6028 ldr r6, [pc, rust-lang#40] ; 3c <__sync_fetch_and_add_4+0x3c> 10: e5954000 ldr r4, [r5] 14: e1a02005 mov r2, r5 18: e1a00004 mov r0, r4 1c: e0841007 add r1, r4, r7 20: e1a0e00f mov lr, pc 24: e12fff16 bx r6 28: e3500000 cmp r0, #0 2c: 1afffff7 bne 10 <__sync_fetch_and_add_4+0x10> 30: e1a00004 mov r0, r4 34: e8bd40f8 pop {r3, r4, r5, r6, r7, lr} 38: e12fff1e bx lr 3c: ffff0fc0 .word 0xffff0fc0 ``` Where you can see the reference to `0xffff0fc0`, which is provided by the [user space helpers].
dotdash
pushed a commit
that referenced
this pull request
Jan 16, 2019
Explain safety for `vec.set_len(0)`
dotdash
pushed a commit
that referenced
this pull request
Jun 18, 2019
Use arenas to avoid Lrc in queries #1 Based on rust-lang#59536.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.