GCC, MSVC, LLVM e probabilmente altre toolchain supportano l'ottimizzazione del tempo di collegamento (intero programma) per consentire l'ottimizzazione delle chiamate tra le unità di compilazione.C'è qualche ragione per non utilizzare l'ottimizzazione del tempo di collegamento?
C'è qualche motivo per non abilitare questa opzione durante la compilazione del software di produzione?
Suppongo che per "software di produzione" si intenda il software spedito ai clienti/in produzione. Le risposte a Why not always use compiler optimization? (gentilmente indicate da Mankarse) si applicano principalmente alle situazioni in cui si desidera eseguire il debug del codice (quindi il software è ancora in fase di sviluppo, non in produzione).
L'unica buona ragione valida che posso pensare è che l'ottimizzazione del tempo di collegamento può introdurre bug sottili, vedere Link-time optimization for the kernel. Supponendo di disporre di test appropriati per verificare la correttezza del software che si sta per spedire, non vedo alcun motivo per non utilizzare LTO di default. (LTO sta diventando più maturo con il tempo, quindi speriamo che quei piccoli bug diventeranno sempre meno frequenti.)
Sono d'accordo con tale risposta. Non ho idea di come non usare LTO di default. Grazie per la conferma. – Honza
@ Honza: Probabilmente perché tende a utilizzare enormi quantità di risorse. Prova a compilare Chromium, Firefox o LibreOffice con LTO ... (FYI: Almeno uno di essi non è nemmeno compilabile su macchine a 32 bit con GNU ld, anche senza LTO, semplicemente perché il working set non si adatta a * virtual * spazio indirizzo!) –
@Honza Sono felice che la mia risposta sia utile. Uso LTO come opzione predefinita nei miei progetti e offre un significativo miglioramento delle prestazioni ai miei programmi (fino a 2,5 volte). Questo è un buon affare dato che devo solo passare '-flto' e basta. :) – Ali
This recent question solleva un altro possibile (ma piuttosto specifico) caso in cui LTO può avere effetti indesiderati: se il codice in questione è strumentato per i tempi e sono state utilizzate unità di compilazione separate per cercare di preservare l'ordine relativo delle dichiarazioni strumentate e strumentali, quindi LTO ha una buona possibilità di distruggere l'ordinamento necessario.
Ho detto che era specifico.
Vedere [Perché non utilizzare sempre l'ottimizzazione del compilatore?] (Http://stackoverflow.com/q/7857601/485561). Le risposte qui sono ugualmente applicabili. – Mankarse
AFAIK, lto per gcc rende il tuo eseguibile più grande e incompatibile con ld, ld è in grado di gestire il tuo oggetto compilato perché esiste effettivamente un plugin per ld dal progetto gcc, ma questo tipo di ottimizzazioni è "non standard" secondo il linker punto di vista. questa idea generale su un oggetto compilato che non è confezionato come gli altri che sono "standard" può portare a tutti i tipi di problemi. – user2485710
@Mankarse Chiede * "durante la compilazione del software di produzione" * così la maggior parte delle risposte non è applicabile. – Ali