Utilizzando bytecode LLVM per le librerie (invece di file oggetto nativo)

Question

Quali sono le implicazioni per

• portabilità (convenzione di chiamata: è veramente importante a livello LLVM in cui solo chiamando in C o funzioni di libreria OS)
• tempo collegamento
• ottimizzazioni

vorrei compilare un linguaggio giocattolo con LLVM, a causa di tutte le parti dure essendo già presente (ottimizzazione, la generazione di codice oggetto), ma sono lottando con un concetto che vorrei mantenere se ne vale la pena: i file di libreria dovrebbero essere ridistribuibili, utilizzabili come lib statici e condivisi (per il collegamento, nel caso condiviso verrà generata una vera e propria o dll quando l'app finale è collegata), portatile. Credo che ciò ridurrebbe una parte del tempo di compilazione (come la generazione del codice nativo e forse l'ottimizzazione viene eseguita una volta sola, al momento del collegamento binario finale). Immagino che il linker si occupi della convenzione di chiamata (se possibile) e della conversione in una libreria condivisa, se richiesta. In un'aggiunta molto estesa, forse LLVM potrebbe essere sfruttato per il collegamento non e utilizzare il JIT LLVM per eseguire direttamente il codice byte generato, rimuovendo completamente i tempi di collegamento durante la scrittura del codice.

Questo suona

1. Fattibile?
2. Ne vale la pena? So che il tempo di collegamento C/C++ è relativamente lungo, il che è problematico quando si ricostruisce frequentemente. Per quanto riguarda l'ottimizzazione del tempo di collegamento gratuito (cfr /GL e -flto poiché sarà essenzialmente collegato il bytecode LLVM, che verrà quindi trasformato in un binario nativo).

Questa potrebbe essere una domanda vaga, se devo chiarire qualcosa, per favore chiedi.

Answer 1

Ho fatto qualcosa di simile a questo in passato. Una cosa che dovresti capire è che il codice a barre LLVM non è "portatile" in quanto non è completamente indipendente dalla macchina. I file di codici a barre hanno una conoscenza di cose come la dimensione dei puntatori, ecc. Che sono specifici per il processore che viene preso di mira.

Detto questo, in passato ho compilato i programmi e le loro librerie di supporto per codificare e collegare i file bitcode insieme prima di generare un file di assembly per l'intero programma. Hai ragione che le convenzioni di chiamata non sono importanti per le chiamate interne, ma le chiamate effettuate all'esterno (o dall'esterno) richiedono comunque che l'ABI sia seguito.

Potresti essere in grado di progettare la lingua del tuo giocattolo in modo tale da evitare il codice bit dipendente dal processore, ma dovrai stare molto attento.

Ho notato che il collegamento dei file di bitcode ha richiesto un po 'di tempo, soprattutto a livelli di ottimizzazione elevati. Che potrebbe essere accelerato ormai, l'ho fatto con LLVM da 2 o 3 anni fa.

Un ultimo punto: a seconda del processore di destinazione, probabilmente sarà necessario l'equivalente di libgcc.a o del compilatore-rt per gestire cose che il processore non può gradire in virgola mobile o roba integer a 64 bit se il processore non lo fa t avere istruzioni che eseguano tali operazioni.