I guess you are right.
Thank you very much for the discussion!
On Wednesday 14 August 2024 at 20:21:01 UTC+3 robert engels wrote:
> My understanding is that optimizations like this are almost never worth it
> on modern processors - the increased code size works against the modern
> branch predi
My understanding is that optimizations like this are almost never worth it on
modern processors - the increased code size works against the modern branch
predictor and speculative executions - vs the single shared piece of code -
there is less possibilities and thus instructions to preload.
> O
> Won’t the speculative/parallel execution by most processors make the JMP
essentially a no-op?
I guess you are right, but this is true when JMP destination already in
instruction buffer. I guess most of these cases are when JMP leads to RET
inside on function, so indeed this optimization will h
Won’t the speculative/parallel execution by most processors make the JMP
essentially a no-op?
See
https://stackoverflow.com/questions/5127833/meaningful-cost-of-the-jump-instruction
> On Aug 14, 2024, at 11:31 AM, Arseny Samoylov
> wrote:
>
> Thank you for your answer!
>
> > We generally do
Hello community, recently I found that gc generates a lot of JMP to RET
instructions and there is no optimization for that. Consider this example:
```
// asm_arm64.s
#include "textflag.h"
TEXT ·jmp_to_ret(SB), NOSPLIT, $0-0
JMP *ret*
ret:
*RET*
*```*
This compiles to :
```
TE
