Hello Jakub!
> You need to be very careful with it, as if there are any jumps
> into the middle of the to be abstracted tail sequences, you can't
> abstract them or would need to adjust also the jumps into them (if
> possible, which not always is).
When wouldn't that possible? My script currently splits on an
instruction-level -- although I would see no problem that some branch
jumps into a "half" opcode of another branch, if the byte sequence
matches.
As I use the disassembly to start from they *have* to converge later -
else I wouldn't have the same end point!
So I think it's just a matter of defining another symbol at that address,
and use that to jump into.
> Also the tail sequence shouldn't contain any PC relative
> references (say you can't merge this was
> movl (.+0xabcd)(%rip), %eax
> ret
> which is byte identical, yet would reference different variables),
That's right ... I didn't think of that.
The script could "forget" the current byte sequences if it encounters %rip
relative adressing.
Note: I only know a bit about i686 and amd64 - for other processors that
would have to be different, of course.
> but even jmp argument is relative, not absolute.
That's why I take only jumps with 32bit arguments - these are absolute.
> You can't do this kind of optimization in the linker, as that's too
> late, many relocations are already relocated and lost during assembly
> and you need to understand the instructions anyway.
> Doing it in GCC would be terribly costly, if that would mean
> expanding everything into RTL, running all RTL passes and instead of
> emitting them, remember the pre-final RTL sequence for each emitted
> function, then do an IPA pass over all the sequences.
> Perhaps doing that in assembler, combined with --combine so that
> assembler can see everything together...
Yes ... I think doing a second compile pass might be the easiest way, and
not much slower than other solutions.
(We could always remember which object files could be optimized, and
only recompile *those*. After all, it's just an additional
optimization.)
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
