Quanto è stabile la lingua dell'assemblaggio LLVM?

Question

Le LLVM Language Reference stati che può essere utilizzato

come una rappresentazione codice binario che su disco (adatto per il caricamento veloce da un compilatore Just-In-Time)

Quanto è stabile questa rappresentazione? Ad esempio, posso generarlo oggi utilizzando LLVM 3.1 e mi aspetto ancora che sia utilizzabile utilizzando un futuro LLVM, ad esempio un ipotetico LLVM 4.5 in tre anni?

Supponendo che non disponga di dipendenze esterne, posso usarlo per generare un binario per un'architettura diversa?

Answer 1

Risposta alla prima domanda: No. Non è stabile. No, non puoi aspettarti che IR/bitcode generato da 3.1 sia leggibile in 4.5 - il progetto LLVM esplicitamente non fornisce questa garanzia, sacrificando la retrocompatibilità a favore della capacità di andare avanti più velocemente, creare migliori ottimizzazioni e strumenti, e refactoring parti del quadro, se necessario. LLVM si rivolge principalmente ai compilatori statici, in anticipo (AOT), quindi questo approccio ha senso per i grandi giocatori.

La seconda domanda che non capisco davvero. LLVM ha obiettivi (backend) per molte architetture e funziona bene per la maggior parte di quelli popolari. Ma ancora una volta, il loro input è IR che è soggetto a modifiche tra le versioni. Assicurarsi inoltre di leggere questo: http://llvm.org/docs/FAQ.html#can-i-compile-c-or-c-code-to-platform-independent-llvm-bitcode, e anche la sezione "Target dipendenza" qui: https://llvm.org/docs/tutorial/LangImpl10.html

Il problema è che quando si chiede su LLVM indipendenza dalla piattaforma molti si chiedono "sarà LLVM IR compilato dal mio codice C essere bersaglio indipendente? ". La risposta a questo è No, perché la C stessa è dipendente dall'obiettivo.

Answer 2

Rispondere alla prima domanda: qui cita la Politica per gli sviluppatori di LLVM.

Quando è necessario modificare il formato IR, tenere presente che si tenta di mantenere una certa compatibilità con le versioni precedenti. Le regole sono intese come un equilibrio tra convenienza per gli utenti di llvm e non impongono un grande onere agli sviluppatori di llvm:

• Il formato testuale non è retrocompatibile. Non lo cambiamo troppo spesso, ma non ci sono promesse specifiche.
• Il formato di bitcode prodotto da una versione X.Y sarà leggibile da tutte le seguenti versioni di X.Z e dalla versione (X + 1) .0.
• Le versioni più recenti possono ignorare le funzionalità delle versioni precedenti, ma non possono eseguirne l'impaginazione. Ad esempio, se nsw viene mai sostituito con qualcos'altro, il suo rilascio sarebbe un modo valido per aggiornare l'IR.
• I metadati di debug sono speciali in quanto sono attualmente eliminati durante gli aggiornamenti.
• I metadati non di debug sono definiti per essere sicuri di essere rilasciati, quindi un modo valido per aggiornarlo è eliminarlo. Non è molto facile da usare e ci si aspetta uno sforzo maggiore, ma non vengono fatte promesse.