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

Setcond handling #26

Open
ercoppa opened this issue Apr 6, 2023 · 3 comments
Open

Setcond handling #26

ercoppa opened this issue Apr 6, 2023 · 3 comments

Comments

@ercoppa
Copy link

ercoppa commented Apr 6, 2023

For instance, let us consider the handling of setcond_i32:

        tcg_gen_op4i_i32(INDEX_op_setcond_i32, ret, arg1, arg2, cond);
        TCGv_i32 cond_temp = tcg_const_i32(cond);
        gen_helper_sym_setcond_i32(
            tcgv_i32_expr(ret), cpu_env,
            arg1, tcgv_i32_expr(arg1),
            arg2, tcgv_i32_expr(arg2),
            cond_temp, ret);
        tcg_temp_free_i32(cond_temp);

This code first executes the concrete computation and then performs the symbolic reasoning. However, when ret is the same TCG temp of arg1 or arg2 there is a problem: the concrete value of arg1 or arg2 taken by the symbolic helper has been already updated by the concrete computation.

To fix this problem, we can make a copy of arg1 or arg2 in case of aliasing with ret to preserve the original value. Let me know if this a reasonable PR or how to improve it.

@enlighten5
Copy link

I think this can be avoided by calling the symbolic helper before generating INDEX_op_setcond_i32.

@ercoppa
Copy link
Author

ercoppa commented Apr 21, 2023

I think the code was written in this was because the symbolic helper takes as input the ret value computed by INDEX_op_setcond_i32.

@enlighten5
Copy link

Yes, you are right. I thought the branch result is computed in the backend.

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

2 participants