Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • M mu-impl-fast
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 40
    • Issues 40
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • mumu
  • mu-impl-fast
  • Issues
  • #34
Closed
Open
Issue created Jun 07, 2017 by Isaac Gariano@igariano01Maintainer

Emitting a 128-bit int constant to a P<Value>

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.

Assignee
Assign to
Time tracking