use atomics where available #8
Conversation
|
@homunkulus try |
|
☀️ Test successful - status-travis |
|
@homunkulus try |
Hmm, looks like the Travis environment doesn't do demangling for some reason. |
|
💔 Test failed - status-travis |
|
@homunkulus try |
|
💔 Test failed - status-travis |
|
I tested running the sanitizer on a minimal Ubuntu 16.04 install and demangling works there. Then I remembered that Travis is using 14.04, which I haven't tested. |
I think this statement might be not exactly true. There are some single core systems that can execute instructions out-of-order, and can break this code. Good news is that Cortex-M is not one of them yet:
I believe that such platforms like Cortex-A9 all have atomic support, so this wouldn't matter in practice, but running non-atomic code on them would probably be a mistake, even if they have only one core. |
|
Good point, @pftbest. I think we should note that (out-of-order execution) in the documentation. I think it's best to ask the user to check the disassembly if they are using a single core system with "no atomics"; if the code is wrong the fix will involve patching the implementation for that specific architecture / target (i.e. |
which works on thumbv6m-none-eabi and probably other targets with max-atomic-width = 0
|
I ended up re-implementing |
|
That's a great idea. |
|
I changed the So, this code: fn exti0() {
unsafe {
RB.split().0.enqueue(0).unwrap();
}
}Produced: With the change, it now produces: TSan seems to be OK with the change. |
|
@homunkulus try |
|
💔 Test failed - status-travis |
|
@homunkulus try |
|
💔 Test failed - status-travis |
|
@homunkulus try |
|
☀️ Test successful - status-travis |
also - add a "`split` freezes the ring buffer" compile fail test - hide compile-fail doc tests - add scoped threads tests
|
@homunkulus r+ |
|
📌 Commit 30ea33c has been approved by |
|
☀️ Test successful - status-travis |
these changes optimize `Vec<u8, 1024>::clone` down to these operations
1. reserve the stack space (1028 bytes on 32-bit ARM) and leave it uninitialized
2. zero the `len` field
3. memcpy `len` bytes of data from the parent
analyzed source code
``` rust
use heapless::Vec;
fn clone(vec: &Vec<u8, 1024>) {
let mut vec = vec.clone();
black_box(&mut vec);
}
fn black_box<T>(val: &mut T) {
unsafe { asm!("// {0}", in(reg) val) }
}
```
machine code with `lto = fat`, `codegen-units = 1` and `opt-level = 'z'` ('z' instead of 3 to avoid loop unrolling and keep the machine code readable)
``` armasm
00020100 <clone>:
20100: b5d0 push {r4, r6, r7, lr}
20102: af02 add r7, sp, #8
20104: f5ad 6d81 sub.w sp, sp, #1032 ; 0x408
20108: 2300 movs r3, #0
2010a: c802 ldmia r0!, {r1}
2010c: 9301 str r3, [sp, #4]
2010e: aa01 add r2, sp, #4
20110: /--/-X b141 cbz r1, 20124 <clone+0x24>
20112: | | 4413 add r3, r2
20114: | | f810 4b01 ldrb.w r4, [r0], #1
20118: | | 3901 subs r1, #1
2011a: | | 711c strb r4, [r3, #4]
2011c: | | 9b01 ldr r3, [sp, #4]
2011e: | | 3301 adds r3, #1
20120: | | 9301 str r3, [sp, #4]
20122: | \-- e7f5 b.n 20110 <clone+0x10>
20124: \----> a801 add r0, sp, #4
20126: f50d 6d81 add.w sp, sp, #1032 ; 0x408
2012a: bdd0 pop {r4, r6, r7, pc}
```
note that it's not optimizing step (3) to an actual `memcpy` because we lack the 'trait specialization' code that libstd uses
---
before `clone` was optimized to
1. reserve and zero (`memclr`) 1028 (!?) bytes of stack space
2. (unnecessarily) runtime check if `len` is equal or less than 1024 (capacity) -- this included a panicking branch
3. memcpy `len` bytes of data from the parent
these changes optimize `Vec<u8, 1024>::clone` down to these operations
1. reserve the stack space (1028 bytes on 32-bit ARM) and leave it uninitialized
2. zero the `len` field
3. memcpy `len` bytes of data from the parent
analyzed source code
``` rust
use heapless::Vec;
fn clone(vec: &Vec<u8, 1024>) {
let mut vec = vec.clone();
black_box(&mut vec);
}
fn black_box<T>(val: &mut T) {
unsafe { asm!("// {0}", in(reg) val) }
}
```
machine code with `lto = fat`, `codegen-units = 1` and `opt-level = 'z'` ('z' instead of 3 to avoid loop unrolling and keep the machine code readable)
``` armasm
00020100 <clone>:
20100: b5d0 push {r4, r6, r7, lr}
20102: af02 add r7, sp, #8
20104: f5ad 6d81 sub.w sp, sp, #1032 ; 0x408
20108: 2300 movs r3, #0
2010a: c802 ldmia r0!, {r1}
2010c: 9301 str r3, [sp, #4]
2010e: aa01 add r2, sp, #4
20110: /--/-X b141 cbz r1, 20124 <clone+0x24>
20112: | | 4413 add r3, r2
20114: | | f810 4b01 ldrb.w r4, [r0], #1
20118: | | 3901 subs r1, #1
2011a: | | 711c strb r4, [r3, #4]
2011c: | | 9b01 ldr r3, [sp, #4]
2011e: | | 3301 adds r3, #1
20120: | | 9301 str r3, [sp, #4]
20122: | \-- e7f5 b.n 20110 <clone+0x10>
20124: \----> a801 add r0, sp, #4
20126: f50d 6d81 add.w sp, sp, #1032 ; 0x408
2012a: bdd0 pop {r4, r6, r7, pc}
```
note that it's not optimizing step (3) to an actual `memcpy` because we lack the 'trait specialization' code that libstd uses
---
before `clone` was optimized to
1. reserve and zero (`memclr`) 1028 (!?) bytes of stack space
2. (unnecessarily) runtime check if `len` is equal or less than 1024 (capacity) -- this included a panicking branch
3. memcpy `len` bytes of data from the parent
290: optimize the codegen of Vec::clone r=japaric a=japaric
these changes optimize `Vec<u8, 1024>::clone` down to these operations
1. reserve the stack space (1028 bytes on 32-bit ARM) and leave it uninitialized
2. zero the `len` field
3. memcpy `len` bytes of data from the parent
analyzed source code
``` rust
use heapless::Vec;
fn clone(vec: &Vec<u8, 1024>) {
let mut vec = vec.clone();
black_box(&mut vec);
}
fn black_box<T>(val: &mut T) {
unsafe { asm!("// {0}", in(reg) val) }
}
```
machine code with `lto = fat`, `codegen-units = 1` and `opt-level = 'z'` ('z' instead of 3 to avoid loop unrolling and keep the machine code readable)
``` armasm
00020100 <clone>:
20100: b5d0 push {r4, r6, r7, lr}
20102: af02 add r7, sp, #8
20104: f5ad 6d81 sub.w sp, sp, #1032 ; 0x408
20108: 2300 movs r3, #0
2010a: c802 ldmia r0!, {r1}
2010c: 9301 str r3, [sp, #4]
2010e: aa01 add r2, sp, #4
20110: /--/-X b141 cbz r1, 20124 <clone+0x24>
20112: | | 4413 add r3, r2
20114: | | f810 4b01 ldrb.w r4, [r0], #1
20118: | | 3901 subs r1, #1
2011a: | | 711c strb r4, [r3, #4]
2011c: | | 9b01 ldr r3, [sp, #4]
2011e: | | 3301 adds r3, #1
20120: | | 9301 str r3, [sp, #4]
20122: | \-- e7f5 b.n 20110 <clone+0x10>
20124: \----> a801 add r0, sp, #4
20126: f50d 6d81 add.w sp, sp, #1032 ; 0x408
2012a: bdd0 pop {r4, r6, r7, pc}
```
note that it's not optimizing step (3) to an actual `memcpy` because we lack the 'trait specialization' code that libstd uses
---
before `clone` was optimized to
1. reserve and zero (`memclr`) 1028 (!?) bytes of stack space
2. (unnecessarily) runtime check if `len` is equal or less than 1024 (capacity) -- this included a panicking branch
3. memcpy `len` bytes of data from the parent
Co-authored-by: Jorge Aparicio <[email protected]>
cc #5
cc @pftbest