gcc LTO optimalizace

Vláďa Anděl vaelektronik na vaelektronik.cz
Sobota Květen 18 22:55:00 CEST 2024


Programování sice není moje hobby a dělám jen jednodušší věci s 8 bit 
silabsama, ale zrovna před pár dny jsem se divil, jak optimalizuje Keil. 
Protože UART mám už obsazený, napsal jsem si pro diagnostiku sériový 
výstup, který pak čtu osciloskopem.
Vypadá to takhle.
void Zobraz()
{
                                         // prenos 438,6 KBd, idle 
level=high, 8 bit
byte Znakdp; byte i=2;
Test=0;                            // start impulz
Znakdp=Znakdisp;
Test=Znakdp&1;            // bit 0
Znakdp>>=1;
Test=Znakdp&1;            // bit 1
Znakdp>>=1;
Test=Znakdp&1;            // bit 2
Znakdp>>=1;
Test=Znakdp&1;            // bit 3
Znakdp>>=1;
Test=Znakdp&1;            // bit 4
Znakdp>>=1;
Test=Znakdp&1;            // bit 5
Znakdp>>=1;
Test=Znakdp&1;            // bit 6
Znakdp>>=1;
Test=Znakdp&1;            // bit 7
do { i--; }
while(i);
Test=1;                            // stop impulz
}
Bylo mi divné, že jedna rotace vychází na 7 strojových cyklů, když 
silabsácká 8051 má většinu instrukcí na jeden strojový cykl (jednu 
periodu oscilátoru). Tak jsem se podíval, jak to překládá. Tady je výpis 
přenosu jednoho bitu.
MOV A, R6
CLR C
RRC, A
MOV R6, A
RRC A
MOV A0.0H, C

Takže místo aby to nechal v A a jen po každé rotaci zkopíroval carry bit 
do výstupu (tady je to A0.0H, tedy bit 0 portu P2), měl to v registru R6 
a po každé rotaci to tam strkal zpátky. Carry vynuluje, protože má 
"naučené", že rotace v céčku není rotace jako v asm, ale že ten carry se 
maže. Takže pak dělá ještě jednu rotaci, aby ten nejnižší bit přepsal do 
carry a carry do portu.

Když jsem chtěl o kousek zpozdit stop bit, původně jsem napsal
i=0;
i++;
To mi při překladu úplně vyhodil. Asi proto, že i se tam dál nepoužívá? 
Když jsem ale napsal
do { i--; }
while(i);
tak to už mi tam nechal. Ostatně proměnná Znakdp se taky pak už dál 
nepoužívá a po každé rotaci jí cpal zpátky do R6. Nevím, jestli je v tom 
nějaký záměr, nebo to tak zkrátka funguje a mám být rád, že to 
funguje... Bohužel, staré silabsácké IDE nezvládá kombinovat céčko a 
assembler. Kolega používá microvision a tam to jde, překladač Keil je v 
tom stejný. Nové simplicity studio by s tím snad už taky nemělo mít 
problém. Zatím jsem neměl sílu a důvod na něj přejít.

Ono teda s assemblerem je u silabsů trochu problém, protože ty mcu mají 
pipeline a jak si načítá instrukce dopředu a při nějakém skoku to zahodí 
a začne znova, podle situace je některá instrukce různě dlouhá. Snad jen 
skoky a volání. Takže assembler a céčko jsem kombinoval jen na starých 
8051, kde to pro přesné časování ještě mělo význam a časovače tam byly 
hodně omezené.

Anděl


Dne 18.05.2024 v 21:47 Miroslav Mraz napsal(a):
> Hm, je to složité, bůhví jak to funguje, kód z toho leze dost hnusný, 
> prostě to nebudu používat. U ARM jsem to nepoužíval taky a šlo to. To 
> jen, že v původních příkladech to bylo použito, tak jsem to zkoušel 
> taky. Moc se to nepovedlo.
>
> Mrazík
>
> On 18. 05. 24 20:00, Jindroush wrote:
>> On 18.05.2024 15:32, Miroslav Mraz wrote:
>>> Víte někdo jak správně používat -flto při překladu pomocí gcc ? V 
>>> poslední době se mi stává, že to vyoptimalizuje i funkce, které jsou 
>>> tam opravdu potřebné. Ale je to u složitějších bare-metal projektů 
>>> RISC-V a tak se mi nedaří vystopovat proč. Clang tím asi tak netrpí, 
>>> tam se to zdá v pořádku.
>>> Setkali jste se s tím třeba na ARM nebo AVR ? 
>> Ja tohle videl a pouzival u MSVC, tak jsem si aspon precet man, abych 
>> vedel, jak to u GCC funguje. Pisou tam zajimavou vec:
>>
>>> it is necessary to make certain whole program assumptions. The 
>>> compiler needs to know what functions and variables can be accessed 
>>> by libraries and runtime outside of the link-time optimized unit. 
>>> When supported by the linker, the linker plugin (see 
>>> -fuse-linker-plugin) passes information to the compiler about used 
>>> and externally visible symbols. When the linker plugin is not 
>>> available, -fwhole-program should be used to allow the compiler to 
>>> make these assumptions, which leads to more aggressive optimization 
>>> decisions. 
>> Tutaj: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>>
>> -- 
>> Jindroush<jindroush na seznam.cz>
>>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list

------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20240518/d3ccc18f/attachment.htm>


Další informace o konferenci Hw-list