On 19/03/17 21:28, Martok wrote:
It's called register spilling: once there are no registers left to hold
values, the compiler has to pick registers whose value will be kept in
I thought it would be something like that...
Still, my main issue was with the repeated fetches. I'd (naively!) say that it
should be relatively easy for an assembly-level optimizer to detect that these
are repeated loads of the same thing, with nothing that could affect the outcome
inbetween. It's not even a CSE in the technical sense, not a sub-expression but
the entire thing...
It is trivial to create a peephole optimization for that particular
pattern. At least if it's just two loads, because after you've optimized
the second load into a register move, the third load no longer fits the
pattern... Unless you create a special peephole optimizer pass that goes
over the code backwards to apply this specific optimization, or you
first match the pattern as many times as possible before changing it.
But then it will still fail if there is at least one other instruction
So then you have to slightly generalise it, and in the end you do end up
with a full-blown assembler CSE optimizer, like the one we removed for
3.0. I'm a staunch believer in not wasting time on stuff like that, it's
just not worth it. Especially since a better register allocator, or SSA,
can probably achieve the same thing in this case.
E.g. those memory loads
are probably optimised by the processor itself (not necessarily coming
even from the L1 cache, but possibly from the write-back buffer).
Not as well as one might believe, manually fixing (by forcing @CurrentHash into
a register with a local variable) just those 4 lines gives a ~2% increase in
MB/s for this hash. Which is quite a lot, given this is the part *without*
You cannot attribute those 2% exclusively to keeping the values in
registers. E.g. removing them can change branch target alignments. Even
adding random nops can get you 10% due to changed code layout.
And again, I've seen this happen more than once on i386 code, where it even
creates "fake" register pressure (by using 2 or more registers to hold exactly
the same temporary)
That's again something that needs to be solved at the register allocator
level (with SSA). Freeing up registers anymore afterwards is useless,
since only the register allocator can keep stuff in them permanently.
fpc-devel maillist - firstname.lastname@example.org