LTO schrieb:
> Wie man sieht, ist der *-Operator (__mulhi3) inline und der %-Operator
> (__divmodhi4) nicht inline bei -Os. Auch bei -flto -fwhole-program
> ändert sich das nicht.
>
> Daher folgende Fragen:
>
> - Warum wird __divmodhi4 hier nicht inline?
Weil das den Code wesentlich vergrößern würde wenn mehr als 1x geinlinet
wird. Auch inline wäre der Code nicht schneller (bis auf CALL/RET, die
aber im Vergleich zum Rest der Routine zu vernachlässigen sind). avr-gcc
kennt den Footprint dieser Funktion, der flacher ist als der üblicher
Calls, z.B. bleibt Z-Reg über den Aufruf erhalten. Der Registerdruck
ist also nur so groß wie tatsächlich durch __[u]divmodhi4 gegeben.
Außerdem berechnen die Funktionen / und %; die Funktion für nur div oder
nur mod wäre kaum kürzer oder schneller, weil ohnehin immer beide
Ergebnisse anfallen.
> - Kann man das irgendwie erzwingen?
Dazu müsstest du die GCC-Quellen anpassen, also gcc/config/avr/avr.md
und den Code dort optinsabhängig inlinen z.B. in insn "[u]divmodhi4".
> - *-Op und &-Op sind als builtins nicht Teil der avr-libc. Deswegen
> wirkt sich hier -flto auch nicht aus, oder?
LTO wirkt sich nur auf die Module aus, für die es gesetzt wird. Wenn es
also inline-Funktionen in Headern gibt (z.B. copysign), sind diese dem
Compiler und damit auch dessen Optimierern zugänglich. Die statischen
Libraries (libc.a, libgcc.a etc.) werden aus gutem Grund nicht mit -flto
generiert.
> Und grundsätzliche Fragen:
> - Gibt es die avr-libc auch als LTO-Verion?
Nein, es sei denn du bastelst deine eigene libgcc / AVR-LibC, die das
kann.
> - Kann ich eine eigene (statische) Bibliothek so gestalten, dass sie
> sowohl Maschinencode als auch GIMPLE (für LTO) enthält?
Sollte prinzipiell möglich sein mit -flto -ffat-lto-objects.
Ein Großteil der AVR-LibC besteht jedoch aus handoptimiertem Assembly,
und bei den großen Brummern wie [v]fprintf würde LTO auch nicht viel
bringen, weil selbst mit LTO nicht analysiert wird / werden kann, welche
%-Codes verwendet werden und welche nicht.
Und die Frage ist dann auch, wie der LTO-Plugin an den LTO-Code in den
Objects der lib*.a kommt, um ihn in lto1 (den LTO-Compiler) zu füttern.
Eigentlich sind aktuelle Binutils Tools wir ranlib alle LTO-fähig, aber
ausprobiert hab ich das nie.
Die zu erwartende Verbesserung der Codegüte ist einfach zu gering, zum
Beispiel sind fast alle Funktionen der libgcc eh in Assembly, außer
einige Funktionen für 64-Bit double, wo der generierte Code aber auch
sehr brauchbar ist (außer möglicherweise für avr-gcc v9+ wegen PR90706,
aber das betrifft dann allen Code, nicht nur den in Libs).