News for hackers. Stuff that matters.
Re:Compiling with Constraints by anonymous_union on Monday March 18, 2024 @05:43PM (#39750413)
its fascinating how register allocation is not a solved problem. thinking about it, it seems like optimal allocation would depend on input/workload, so any ahead of time selection will always be a compromise.
Re:Compiling with Constraints by JonChesterfield on Monday March 18, 2024 @06:08PM (#39750654)
It's np hard. You can solve it perfectly for a given instance using a constraint solver and adequate patience.

Unfortunately instruction selection is also NP, and so is instruction scheduling, and all three are inter-related. An optimal solution for one tends to be suboptimal for the other two.

Ideally one would feed all three problems into a constraint solver together. Thus far this is considered computationally infeasible, though I don't think that belief would bear up to scrutiny with a supercomputer.

Re:Compiling with Constraints by LoganDark on Monday March 18, 2024 @06:49PM (#39750987)
> though I don't think that belief would bear up to scrutiny with a supercomputer.

It's certainly computationally infeasible for home users, that's for sure.

Re:Compiling with Constraints by PhilipRoman on Tuesday March 19, 2024 @04:53AM (#39753935)
>You can solve it perfectly for a given instance using a constraint solver and adequate patience.

Is this really true for cases where there is no choice but to spill registers? How would a graph coloring solver understand to spill outer loop variables instead of inner loop ones? I've never written a "proper" register allocator so I'm curious.

Re:Compiling with Constraints by mzl on Tuesday March 19, 2024 @05:22AM (#39754063)
The article links to the Unison project, which does optimal spilling and register allocation using constraint programming solvers.

The core idea is that memory for spilling is treated as an additional set of register-like locations, with costs for using.

Re:Compiling with Constraints by philzook on Monday March 18, 2024 @06:01PM (#39750580)
I think one of the biggest problems is even stating what the solution an optimal compiler would be. How does one model a program or a CPU? There almost certainly isn't one perfect model for all situations. CPU's are extremely complicated despite the surface simplicity of assembly. Naive notions of registers or instruction ordering don't really exist. But also because of this, perfect compilation isn't that crucial. The CPU kind of JITs for you. The only objective function that seems pretty clear to me is code size.
Re:Compiling with Constraints by anonymous_union on Monday March 18, 2024 @06:13PM (#39750695)
right yea, modern CPUs seem to have all sorts of abstract optimizations. its kind of strange how we meet in the middle with hardware ISA manufacturers. they do all sorts of tricks on their side to make code go faster, and we try to generate machine code that we think will go faster, but neither side works with the other (compiler writers and ISA developers). i bet there is easy low hanging fruit here.
Re:Compiling with Constraints by LoganDark on Monday March 18, 2024 @06:50PM (#39751003)
There sort of is, but isn't that why stuff like VLIW exists? So that the compiler can optimize the hell out of the machine code, and the CPU doesn't have to do its own OoO nonsense?
Re:Compiling with Constraints by philzook on Monday March 18, 2024 @07:09PM (#39751143)
VLIW is what the Unison project (the context behind this post) was attacking. https://unison-code.github.io/ My best understanding is that exposing the details of the CPU to the compiler via a more complex ISA has not worked that well. Possibly because the compilation problem just gets too hard, but maybe also for momeentum and ecosystem reasons. I think another lesson is that it is unwise to make your isa expose microarchitecture because microarchitecture changes quite a bit between generations and inidividual CPUs. Things like delay slots seem like misfeatures now.
Re:Compiling with Constraints by gsnedders on Monday March 18, 2024 @08:20PM (#39751649)
And it's worth noting VLIW survived longer in GPUs—where there isn't any expectation of ISA stability, which avoids that problem.
Re:Compiling with Constraints by remexre on Monday March 18, 2024 @09:39PM (#39752161)
And, perhaps also relevantly, your compute kernel probably fits in iCache, even with VLIW instructions.
Re:Compiling with Constraints by LoganDark on Monday March 18, 2024 @07:12PM (#39751184)
Not to be confused with the Unison language, I guess. https://www.unison-lang.org
Re:Compiling with Constraints by anonymous_union on Monday March 18, 2024 @06:15PM (#39750713)
interesting that code size is important to you. hey everyone, write shorter programs :)
Re:Compiling with Constraints by philzook on Monday March 18, 2024 @07:10PM (#39751155)
I do like short programs :). Code size does matter for instruction cache. In my application in particular, post hoc binary patching, a single byte can make a big difference in difficulty of patching.
Re:Compiling with Constraints by Joker_vD on Tuesday March 19, 2024 @10:58AM (#39756384)
Maybe we should just make our ISAs be memory-memory, and let the chips map memory addresses onto its hundreds of registers internally, serving as a L0 cache of a sort: after all, we the programmers don't manage L1/L2/L3 caches manually, do we? The CPUs do it transparently for us.
Re:Compiling with Constraints by thechao on Monday March 18, 2024 @06:13PM (#39750696)
If you're willing to work in the SSA domain, and not do any spill/fill, you can do optimal RA in polynomial time. (Usually quoted as linear, but quadraticish IRL.)
Re:Compiling with Constraints by convolvatron on Monday March 18, 2024 @05:45PM (#39750438)
certainly optimal would be global, and I'm pretty sure its isomorphic to bin packing..whether you use a fixed call interface or not. so its solved, its just exponential
Re:Compiling with Constraints by anonymous_union on Monday March 18, 2024 @05:59PM (#39750560)
im not sure. given a hypothetical arch with only 1 free register, which local variable do you allocate to it?

  1 int
  2 main(int argc, char *argv[])
  3 {
  4         int sum = 0;
  5         int sum2 = 0;
  6
  7         if (argc >= 2)
  8                 for (int i = 0; i < argv[1]; i++)
  9                         sum += i;
 10
 11         if (argc >= 3)
 12                 for (int i = 0; i < argv[2]; i++)
 13                         sum2 += sum + i;
 14
 15         return 0;
 16 }
Re:Compiling with Constraints by anonymous_union on Monday March 18, 2024 @06:01PM (#39750572)
oops im dumb, convert argv[1] and argv[2] to integers first.
Re:Compiling with Constraints by T_MacThrowFace on Monday March 18, 2024 @09:52PM (#39752226)
youngun, this is why line numbers always increase by 10
Re:Compiling with Constraints by UncleEntity on Tuesday March 19, 2024 @02:08AM (#39753350)
Oh, I want to play...

So, an optimizing compiler would see that pretty much everything is dead code it would assign 0 to the return register and done.

Re:Compiling with Constraints by canucker2016 on Tuesday March 19, 2024 @04:19PM (#39759837)
I changed the return stmt to "return sum2" so the for-loop calculations aren't optimized away and fed the code to godbolt.org (compiler explorer).

gcc-trunk at -O3 for x64 will vectorize the loops but there's no register pressure, so the register allocator wasn't taxed much.

No niche optimization pass to convert to using Gauss's shortcut - https://physicsdb.com/sum-natural-numbers/

Re:Compiling with Constraints by canucker2016 on Tuesday March 19, 2024 @04:33PM (#39759936)
x86-64-icx-latest and x86-64-clang-trunk use the Gauss shortcut.

wow. wonder if there's much use for that optimization pattern.

edit: clang discussion https://stackoverflow.com/questions/74417624/how-does-clang-...

Re:Compiling with Constraints by Someone on Tuesday March 19, 2024 @04:43AM (#39753901)
> given a hypothetical arch with only 1 free register, which local variable do you allocate to it?

A truly good compiler would use the same register for sum and sum2 and for argv[1] and argv[2] if it needs to, (even if they weren’t dead, as in this toy example)

With only one register, the answer probably will be “none or every single one”, depending on the instruction set, though.

For example, how do you index into arrays? Self modifying code as often is done on the 6502? Or do you have stack-relative indirect addressing that allows you to say “add the contents of the address pointed to by the value at stack pointer plus 6 to the register”? Either way, there will be lots of contention for that single register.

Or does this hypothetical architecture have various complex “add contents of addresses foo[register] and bar and store the result in baz[3] instructions? (Which would probably make it a very bad design. Adding a second register would be about the first thing to do (fun fact: the 4004 had 16 registers), but maybe this hypothetical design has RAM that’s as fast as registers?)