GitLab

Currently the functions emit_ireg_value and emit_reg_value in aarch64/mod.rs and emit_reg in x86_64\inst_sel.rs are unimplemented when the source value/tree_node is a Constant::IntEx. This will cause a problem if you try and and do a 128-bit UDIV/UREM/SREM/SDIV (it will call unimplemented!())

E.g. compiling the following code will fail with 'panic not yet impelemented'

.funcdef foo<()->()>
{
        entry():
                %v = UREM <int<128>> <int<128>>1 <int<128>>1
                RET
}

(but only when using muc with -c , it works when using muc with -r (this is probably a bug in muc, I will look into it).

I believe the simplest solution would be to have some way of combining two P<Value>s into one. (Basically have a function that is the inverse of split_int128). That way we could use the same code for emit_ireg_ex and then instead of returning a pair of P<Value>'s we return a P<Value> constructed by combining these two.

I release the reason for this bug is that I have modified run time entry points for UDIV/UREM/SREM/SDIV to take a int<128> arguments, and so we need to pass a single P<Value> to the call to emit_runtime_entry, wheras before when using int<64> arguments we were passing 2 P<Value>'s for each 128-bit integer.