Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help: move operations simplification #187

Open
bagggage opened this issue Jan 20, 2025 · 0 comments
Open

Help: move operations simplification #187

bagggage opened this issue Jan 20, 2025 · 0 comments

Comments

@bagggage
Copy link

Problem

I have a certain code generator based on bunny-jit where I often have to make calls to external functions by address. I frequently find myself in the following situation:

...
movabs rcx, 0x55556533aef0
movabs r9, 0x555558c79c20
mov rsi, rdi
mov rdi, rcx
mov rbx, rdx
xor edx, edx
mov rcx, rsp
mov rax, r9
call rax
...

This is part of the result of compiling some code that involves a function call with 4 arguments. The first thing that stands out is the pointless loading of the function address into r9 instead of just loading it directly into rax. This happens consistently, and it’s likely related to the fact that the frontend’s Proc::i/d/tcallp takes it as the first argument, and I use Proc::lcu before calling Proc::i/d/tcallp. Afterward, the frontend itself generates opcodes for loading the arguments. Thus, first comes the address, then the arguments, and then the call, which again requires the address.

A similar problem occurs with the arguments themselves: values are constantly being shuffled between registers instead of computations being performed directly in the desired registers to avoid unnecessary mov instructions.

Question

Where can I find the implementation code related to this, the optimization passes, etc.? I’d like to improve this and possibly implement some optimizations if it turns out to be feasible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant