News for hackers. Stuff that matters.

A comment on CPU registers and OCaml. Parent comment

Re:CPU registers and OCaml by rayiner on Sunday June 21, 2015 @12:27PM (#9753964)
Look at the live ranges in the function (the range between where a variable is defined and where it is used, i.e. the range over which the variable has a value that must be preserved because it will be used in the future). Generally register allocation algorithms will be able to assign different variables to the same register if their live ranges do not interfere (i.e. overlap). If live ranges overlap, that means their value needs to be preserved simultaneously, and they can't use the same register.

In the code, there is a lot of overlapping live ranges. E.g. ax and xx. Those can be eliminated by moving code around, but most register allocators do not move code.

[ Parent | on HN ]
Re:CPU registers and OCaml by cosmicexplorer on Sunday June 21, 2015 @12:32PM (#9753977)
Is there not like a "-O3" option to try aggressive code manipulation like that? Or is moving code around just not done at all because it's difficult to do correctly?
[ Parent | on HN ]
Re:CPU registers and OCaml by pcwalton on Sunday June 21, 2015 @12:45PM (#9754025)
I think rematerialization covers most of the cases in which you would benefit from doing that (such as ax and xx), and rematting is standard in advanced compilers like GCC/LLVM.
[ Parent | on HN ]
Re:CPU registers and OCaml by pcwalton on Sunday June 21, 2015 @12:43PM (#9754019)
A lot of register allocators can rematerialize, though, and that can have much the same effect. (ax and xx should be candidates for rematting.)
[ Parent | on HN ]
Re:CPU registers and OCaml by rayiner on Sunday June 21, 2015 @01:21PM (#9754149)
Good point. Though rematerialization is still pretty rare considering the entire universe of compilers (e.g. Academic projects like Ocaml was).
[ Parent | on HN ]
Re:CPU registers and OCaml by pcwalton on Sunday June 21, 2015 @01:22PM (#9754158)
Yeah, I was always under the impression that ocamlopt is fairly Plan 9-like; it produces medium quality code quickly, and doesn't have the full suite of compiler optimizations that projects like LLVM or HotSpot have.
[ Parent | on HN ]