Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
pypy
pypy
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 603
    • Issues 603
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 13
    • Merge Requests 13
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

This instance will be upgraded to Heptapod 0.21.0rc2 on 2021-04-16 at 11:00 UTC+2 (a few minutes of down time)

  • PyPy
  • pypypypy
  • Issues
  • #2244

Closed
Open
Created Feb 26, 2016 by Bitbucket Importer@bitbucket_importerMaintainer

Register allocation

Created originally on Bitbucket by plan_rich (Richard Plangger)

During the sprint in Leysin (2016) Remi and I have refactored the register allocator. The most notably change is to take call sites into account and prefer callee saved regsiters for live ranges that survive the call site. Another change was that live ranges do not change the register they are assigned to, unless a spilling operation takes place. Before that a live range could just change the assigned register at e.g. a int_add operation. The last property described can make reasoning a lot easier, but currently seems to generate some more moves (registers).

There where some gains and some losses at others. So it was around +/- 1%.

We still think there is more that can be improved going the following way:

Live range splits. This is the most sensible feature we need to implement! Because of unroll we can have very very long live ranges that allocate a register. We probably want to split them be for entering the peeled loop.

The changes are located in the branch fix-longevity.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None