It looks like the old `__rust_probestack` routine is incompatible with newer
linux kernels. My best guess for this is that the kernel's auto-growth logic is
failing to trigger, causing what looks like a legitimate segfault to get
delivered. My best guess for why *that's* happening is that the faulting address
is below `%rsp`, whereas previously all faulting stack addresses were above
`%rsp`. The probestack routine does not modify `%rsp` as it's probing the stack,
and presumably newer kernels are interpreting this as a legitimate violation.
This commit tweaks the probestack routine to instead update `%rsp` incrementally
as probing happens. The ABI of the function, however, requires that `%rsp`
isn't changed as part of the function so it's restored at the end to the
previous value.
Use the Rust implementation of udivsi3 on ARM
Although compiler-rt presumably has a more optimized implementation written in
assembly, it appears buggy for whatever reason, causing #173.
For now let's see if integration into rust-lang/rust will work with the
Rust-defined implementation!
Although compiler-rt presumably has a more optimized implementation written in
assembly, it appears buggy for whatever reason, causing #173.
For now let's see if integration into rust-lang/rust will work with the
Rust-defined implementation!
optimize memset and memclr for ARM
This commit optimizes those routines by rewriting them in assembly and
performing the memory copying in 32-bit chunks, rather than in 8-bit chunks
as it was done before this commit. This assembly implementation is
compatible with the ARMv6 and ARMv7 architectures.
This change results in a reduction of runtime of about 40-70% in all cases
that matter (the compiler will never use these intrinsics for sizes smaller
than 4 bytes). See data below:
| Bytes | HEAD | this PR | diff |
| ----- | ---- | ------- | ---------- |
| 0 | 6 | 14 | +133.3333% |
| 1 | 10 | 13 | +30% |
| 2 | 14 | 13 | -7.1429% |
| 3 | 18 | 13 | -27.77% |
| 4 | 24 | 21 | -12.5% |
| 16 | 70 | 36 | -48.5714% |
| 64 | 263 | 97 | -63.1179% |
| 256 | 1031 | 337 | -67.3133% |
| 1024 | 4103 | 1297 | -68.389% |
All times are in clock cycles. The measurements were done on a Cortex-M3
processor running at 8 MHz using the technique described [here].
[here]: http://blog.japaric.io/rtfm-overhead
---
For relevance all pure Rust programs for Cortex-M microcontrollers use memclr to
zero the .bss during startup so this change results in a quicker boot time.
Some questions / comments:
- ~~the original code (it had a bug) comes from this [repo] and it's licensed
under the ICS license. I have preserved the copyright and license text in the
source code. IANAL, is that OK?~~ no longer applies. The intrinsics are written in Rust now.
- ~~I don't know whether this ARM implementation works for ARMv4 or ARMv5.
@FenrirWolf and @Uvekilledkenny may want to take look at it first.~~ no longer applies. The intrinsics are written in Rust now.
- ~~No idea whether this implementation works on processors that have no thumb
instruction set. The current implementation uses 16-bit thumb instructions.~~ no longer applies. The intrinsics are written in Rust now.
- ~~The loop code can be rewritten in less instructions but using 32-bit thumb
instructions. That 32-bit version would only work on ARMv7 though. I have yet
to check whether that makes any difference in the runtime of the intrinsic.~~ no longer applies. The intrinsics are written in Rust now.
- ~~I'll look into memcpy4 next.~~ done
[repo]: https://github.com/bobbl/libaeabi-cortexm0
* Don't run `intrinsics` tests on thumb
* Disable `compiler_builtins` attribute on `feature = "gen-tests"`
* Disable mangling on `feature = "gen-tests"` instead of `cfg(test)`
Alex Crichton
bors
Jorge Aparicio