[Arm32-JIT] Elixir fixes#25
Conversation
Co-authored-by: Frank Hunleth <fhunleth@troodon-software.com>
This binary OP might generate too much code. We cannot wait the next check. We need to act within this emitter. Co-authored-by: Frank Hunleth <fhunleth@troodon-software.com>
Co-authored-by: Frank Hunleth <fhunleth@troodon-software.com>
| a.asr(TMP, TMP, imm(_TAG_IMMED1_SIZE)); | ||
|
|
||
| if (Base.get() != 0) { | ||
| if (Support::isUInt12((Sint)Base.get())) { |
There was a problem hiding this comment.
This change fixes a bug while loading Elixir.String.Tokenizer.
This caused the next line to emit sub r12 r12 257 which is illegal.
| // This emitter may introduce more code then expected. | ||
| // This may overshoot the 4KB displacement limit of few constants. | ||
| // To avoid it we check the pending stubs between every segment. | ||
| check_pending_stubs(); |
There was a problem hiding this comment.
During loading of module Elixir.Exceptions this emitter was producing more then 2KB of assembly.
This was breaking asmjit code generation as the next stub creation was forced to handle a displacement value that was over 4KB.
The displacement happened to be over 4KB by 100~200 bytes
There was a problem hiding this comment.
@fhunleth while rebasing on maint-27 I realized that the OTP team fixed THIS same BUG in 27.2, they basically did the same fix for arm64, but added the check_pending_stubs at the end of the loops, which sligthly makes more sense.
|
@fhunleth please let me know if these fixes are also working on your hardware. I tested with qemu and I think I pinpointed the issues you experienced. |
|
@ziopio This is great! Thank you for digging through all of that AI code I shared. I'll should be able to try it out tomorrow! |
|
@fhunleth these commits are already on the branch |
|
@ziopio This branch didn't work, but it is really close. To make it work, I only had to add this change: |
This PR is inspired by #23