I. Introduction▲
Dans mon article précédent sur ce sujet, j’ai décrit comment j’ai essayé d’utiliser LLVM et clang pour exécuter certains tests préliminaires de compilation C++ dynamique. Maintenant, dans ce post, je veux pousser ce concept un peu plus loin et construire un compilateur JIT fonctionnel, que je puisse éventuellement utiliser en production, soit directement, soit depuis du code C++ ou Lua ou d’autres interfaces.
II. Classe de base d’interface JIT▲
Jusqu’ici, j’ai seulement testé une seule opération de compilation avec un seul appel de fonction (runClang(W:/Projects/NervSeed/temp/test1.cxx)). La première chose que j’ai décidé de faire ensuite a été d’encapsuler la logique de compilation LLVM dans une classe appropriée, que je puisse utiliser pour exécuter « plusieurs étapes de compilation » et de multiples « étapes d’appel de fonction ». Comme cet exemple en pseudocode :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
JIT* jit = new MyJITClass();
jit->loadModule("my_file1.cpp");
typedef int(*Func)(int)
Func func = (Func)jit->lookup("my_print_number_function")
func(42);
jit->loadModule("my_file2.cpp");
typedef int(*AddFunc)(int,int);
AddFunc add = (AdddFunc)jit->lookup("my_add_function");
add(3,5);
Donc, avec cet usage en tête, je suis arrivé à la déclaration initiale suivante pour ma classe NervJIT :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
#include <llvm_common.h>
namespace nv
{
struct NervJITImpl;
class NVLLVM_EXPORT NervJIT : public nv::RefObject
{
private:
std::unique_ptr<NervJITImpl> impl;
public:
NervJIT();
~NervJIT();
void loadModuleFromFiles(const FileList& files) {
for(auto& f: files) {
loadModuleFromFile(f);
}
}
void loadModuleFromFile(const std::string& file);
void loadModuleFromBuffer(const std::string& buffer);
uint64_t lookup(const std::string& name);
};
};
Quelques points-clés pour le code ci-dessus :
-
cette classe fournit juste le support pour :
- Compiler un fichier source ou un tampon source et charger le résultat en tant que « module » dans le contexte du « contexte du JIT LLVM » d’où nous pouvons extraire les fonctions compilées et les exécuter dynamiquement. C’est fait avec loadModuleFromFile et loadmoduleFromBuffer, évidemment,
- Récupérer un pointeur sur une fonction compilée qui puisse ensuite être utilisé comme une fonction normale depuis le process hôte. C’est ce que nous faisons dans la fonction lookup ci-dessus ;
- j’utilise une classe de base nv::RefObject simplement pour fournir un mécanisme de base de « pointeur intelligent intrusif » que j’ai de toujours utilisé (oui, je sais, la plupart des gens utiliseraient std::unique_ptr ou std::shared_ptr en C++ moderne, mais je pense toujours qu’un comptage de références intrusif est parfois une meilleure idée
). De toute façon, ça ne devrait pas être un souci ici ;
- j’ai utilisé l’idiome d’implémentation caché (c’est-à-dire ce membre impl ci-dessus) pour cacher tout ce qui concerne LLVM, les en-têtes sont massifs et complexes, je ne veux donc pas maintenir une dépendance externe à eux ;
- le type FileList est simplement un vecteur de strings (i.e. : std::vector<std::string>), j’ai juste ajouté une méthode utilitaire loadModuleFromFiles pour pouvoir compiler plusieurs fichiers à la fois (mais je doute réellement que ce soit vraiment utile à la fin).
Puis, dans le fichier d’implémentation, ces fonctions seront simplement redirigées vers le membre de NervJITImpl comme suit :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
NervJIT::NervJIT()
{
logDEBUG("Creating NervJIT object.");
impl = std::make_unique<NervJITImpl>();
logDEBUG("Done creating NervJIT object.");
}
NervJIT::~NervJIT()
{
logDEBUG("Deleting NervJIT object.");
impl.reset();
logDEBUG("Deleted NervJIT object.");
}
void NervJIT::loadModuleFromBuffer(const std::string& buffer)
{
CHECK(impl, "Invalid NervJIT implementation.");
auto& compilerInvocation = impl->compilerInstance->getInvocation();
auto& frontEndOptions = compilerInvocation.getFrontendOpts();
frontEndOptions.Inputs.clear();
std::unique_ptr<MemoryBuffer> buf = llvm::MemoryBuffer::getMemBuffer(llvm::StringRef(buffer.data(), buffer.size()));
frontEndOptions.Inputs.push_back(clang::FrontendInputFile(buf.get(), clang::InputKind(clang::Language::CXX)));
impl->loadModule();
}
void NervJIT::loadModuleFromFile(const std::string& file)
{
CHECK(impl, "Invalid NervJIT implementation.");
// We prepare the file list:
auto& compilerInvocation = impl->compilerInstance->getInvocation();
auto& frontEndOptions = compilerInvocation.getFrontendOpts();
frontEndOptions.Inputs.clear();
frontEndOptions.Inputs.push_back(clang::FrontendInputFile(llvm::StringRef(file), clang::InputKind(clang::Language::CXX)));
impl->loadModule();
}
uint64_t NervJIT::lookup(const std::string& name)
{
THROW_IF(!impl, "Invalid NervJIT implementation.");
return impl->lookup(name);
}
Dans le code précédent, nous voyons que nous avons déjà des interactions avec des objets LLVM dans les fonctions de loadModule : fondamentalement, je récupère l’objet compilerInstance qui fait partie de NervJITImpl, puis je mets à jour sa liste de « fichiers » d’entrée avant d’appeler la véritable fonction de compilation [c’est-à-dire loadModule()]. Ainsi, à la fin, que les entrées proviennent d’un fichier ou d’un tampon en mémoire ne fait aucune différence après que la liste frontale Inputs a été mise à jour.
Vous vous demandez sans doute pourquoi j’ai ajouté la fonction loadModuleFromFiles ! Après tout, nous pourrions juste faire un push_back des différents fichiers dans le vecteur frontEndOptions.Inputs ci-dessus pour obtenir le même résultat plus efficacement… Eh bien, en fait, non. Ça ne semble pas fonctionner : lorsque j’essaye de procéder ainsi, il semble que le compilateur veuille réellement trouver et analyser tous les fichiers fournis en entrée, mais ensuite l’objet Module généré ne contient que les fonctions du dernier fichier de la liste… jusqu’ici, je n’ai vraiment aucune idée du pourquoi, malheureusement.
III. Classe d’implémentation du JIT▲
Nous abordons maintenant le cœur de l’implémentation du compilateur.
Comme dit plus haut, la compilation réelle est effectuée dans la structure NervJITImpl, qui est déclarée comme suit (gardez juste à l’esprit que nous avons mis cette déclaration directement dans le fichier .cpp, rien n’est donc visible dans l’interface NervJIT) :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
#define NV_MAX_FUNCTION_NAME_LENGTH 256
namespace nv
{
typedef std::unordered_map<std::string, std::string> FunctionNameMap;
struct NervJITImpl {
std::unique_ptr<llvm::orc::LLJIT> lljit;
clang::IntrusiveRefCntPtr<clang::DiagnosticOptions> diagnosticOptions;
std::unique_ptr<clang::TextDiagnosticPrinter> textDiagnosticPrinter;
clang::IntrusiveRefCntPtr<clang::DiagnosticIDs> diagIDs;
clang::IntrusiveRefCntPtr<clang::DiagnosticsEngine> diagnosticsEngine;
std::unique_ptr<llvm::orc::ThreadSafeContext> tsContext;
std::unique_ptr<clang::CodeGenAction> action;
std::unique_ptr<clang::CompilerInstance> compilerInstance;
std::unique_ptr<llvm::PassBuilder> passBuilder;
std::unique_ptr<llvm::ModuleAnalysisManager> moduleAnalysisManager;
std::unique_ptr<llvm::CGSCCAnalysisManager> cGSCCAnalysisManager;
std::unique_ptr<llvm::FunctionAnalysisManager> functionAnalysisManager;
std::unique_ptr<llvm::LoopAnalysisManager> loopAnalysisManager;
std::unique_ptr<clang::LangOptions> langOptions;
llvm::ModulePassManager modulePassManager;
FunctionNameMap functionNames;
char tmpFuncName[NV_MAX_FUNCTION_NAME_LENGTH];
NervJITImpl();
~NervJITImpl();
void loadModule();
uint64_t lookup(const std::string& name);
};
}
Comme vous le voyez ci-dessus, cette structure est utilisée pour conserver les références sur tous les objets LLVM utilisés durant la compilation JIT. Nous configurons ces objets durant la construction de notre objet NervJITImpl avec le constructeur suivant :
Le code précédent est assez similaire au code de test initial que j’ai utilisé dans l'article précédent, mais contient certaines mises à jour importantes que nous discutons ici.
III-A. Fonction auxiliaire CHECK_LLVM▲
J’ai introduit quelques fonctions pour gérer les erreurs et exceptions de LLVM de manière plus « intégrée » : dans LLVM, beaucoup de fonctions renvoient des valeurs Expected<T> qui peuvent contenir des messages d’erreur, plutôt que… une valeur de type T, évidemment. Ensuite, le framework fournit aussi une classe auxiliaire typique nommée ExitOnError, que vous pouvez utiliser pour encapsuler vos appels à ces fonctions LLVM telles que celle-ci par exemple :
lljit = ExitOnErr(LLJITBuilder().create());Cependant, cette classe auxiliaire affichera le message d’erreur sur la sortie standard (ou au moins sur ce qui est mappé sur llvm::errs() selon ce que je comprends), puis terminera immédiatement le processus par un appel à exit(exitCode). Je voudrais plutôt gérer l’affichage et la gestion d’erreurs par moi-même et j’utilise mes macros/journaux habituels pour le faire. Et ça semble fonctionner aussi bien jusqu’ici.
III-B. Chemins de recherche des en-têtes mis à jour▲
Le second grand changement dans le code précédent est la mise à jour des chemins de recherche des en-têtes :
2.
3.
4.
5.
6.
7.
8.
9.
10.
auto& headerSearchOptions = compilerInvocation.getHeaderSearchOpts();
headerSearchOptions.Verbose = false;
headerSearchOptions.UserEntries.clear();
headerSearchOptions.AddPath("D:/Apps/VisualStudio2017_CE/VC/Tools/MSVC/14.16.27023/include", clang::frontend::System, false, false);
headerSearchOptions.AddPath("C:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/um", clang::frontend::System, false, false);
headerSearchOptions.AddPath("C:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/shared", clang::frontend::System, false, false);
headerSearchOptions.AddPath("C:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/ucrt", clang::frontend::System, false, false);
headerSearchOptions.AddPath("C:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/winrt", clang::frontend::System, false, false);
En réalité j’ai d’abord mis à jour mon fichier test2.cxx avec ce contenu :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
#include <string>
int nv_add2(int a, int b)
{
return (a+b)*2;
}
int nv_sub2(int a, int b)
{
return (a-b)*2;
}
int nv_length(const std::string& input)
{
return input.size();
}
Comme vous pouvez l’imaginer, sans la mise à jour des chemins des en-têtes ci-dessus, le compilateur ne pouvait pas trouver l’inclusion de <string> et produisait donc une erreur. Le fichier <string> fait partie des fichiers d’en-tête de Visual Studio, donc du premier chemin d’inclusion, mais, bien sûr, vous avez ensuite des fichiers inclus récursivement et vous finissez par une dépendance au Windows SDK, que je fournis par les quatre chemins d’inclusion suivants.
Note : coder en dur tous ces chemins n’est clairement pas la bonne manière de faire… je corrigerai cela à l’occasion
III-C. Arguments de la ligne de commande mis à jour pour la création de l’invocation du compilateur▲
En même temps que je fournissais un chemin correct pour trouver le fichier <string>, j’ai commencé à recevoir une grande quantité d’erreurs étranges de clang qui essayait de compiler mon fichier (par exemple, des erreurs de syntaxe ou de types non définis… tous inclus dans les en-têtes système, évidemment). Ceci m’a conduit à un autre changement majeur de la liste des arguments de la ligne de commande passée à la fonction auxiliaire que nous utilisons pour configurer l’invocation du compilateur de notre compilerInstance :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
std::stringstream ss;
ss << "-triple=" << llvm::sys::getDefaultTargetTriple();
std::vector<const char*> itemcstrs;
std::vector<std::string> itemstrs;
itemstrs.push_back(ss.str());
// cf. https://clang.llvm.org/docs/MSVCCompatibility.html
// cf. https://stackoverflow.com/questions/34531071/clang-cl-on-windows-8-1-compiling-error
itemstrs.push_back("-x");
itemstrs.push_back("c++");
itemstrs.push_back("-fms-extensions");
itemstrs.push_back("-fms-compatibility");
itemstrs.push_back("-fdelayed-template-parsing");
itemstrs.push_back("-fms-compatibility-version=19.00");
itemstrs.push_back("-std=c++17");
- Tous les indicateurs -fxxx sont requis pour la compatibilité avec « la version Microsoft » des fichiers d’en-tête C++ standards disponibles dans Visual Studio (tels que <string>). De nouveau, ceci n’a de sens que si vous programmez sous Windows avec Visual Studio, mais, d’après ce que j’ai compris, clang peut aussi présenter certaines incompatibilités avec les en-têtes de GCC, ce qui peut exiger certains autres indicateurs sur la ligne de commande pour être corrigé : gardez ceci en tête.
- Peut-être plus surprenant, alors que je tentais de corriger les erreurs de clang, j’ai décidé de spécifier le niveau du langage C++ sur la ligne de commande également (avec les options -std==c++11 / c++14 / c++17) et j’ai obtenu l’erreur suivante :
error: invalid argument '-std=c++17' not allowed with 'C'Donc, ça signifie que le langage par défaut configuré pour l’exécution de mon compilateur était en réalité C et non C++ et, en fait, en y réfléchissant plus soigneusement, dans mon article précédent, j’aurais pu récupérer les symboles des fonctions que j’ai créées (par exemple, nv_add, nv_sub) en utilisant juste ces noms, car il n’y avait pas de décoration de nom à l’œuvre ! Et ceci, bien que j’aie spécifié clang::InputKind(clang::Language::CXX) comme type pour le fichier d’entrée que je fournissais… Ainsi, il semble que clang compilait joyeusement mes fichiers source C++ comme des sources C, jusqu’à ce que j’inclue l’entête <string>… ne me demandez pas pourquoi !
Après cela, même si j’obtenais toujours d’abord l’erreur ci-dessus (invalid argument '-std=c++17' not allowed with 'C'), les noms de fonction apparurent décorés (comme ?nv_add@@YAHHH@Z) et je ne pus les récupérer aussi facilement qu’auparavant. Je pense donc que c’est là que j’ai commencé à compiler vraiment en C++ pour la première fois (mieux vaut tard que jamais
Puis j’ai voulu me débarrasser de cette erreur de langage par défaut (il valait toujours C), j’ai donc explicitement demandé à clang de compiler du « contenu C++ » par les arguments de ligne de commande “-x c++”, et ça a marché…
Comme on peut le lire dans la ligne de code commentée ci-dessus, j’ai aussi trouvé la fonction setLangDefaults que nous pouvons apparemment appeler pour ajuster la définition du langage par défaut… J’ai pensé l’utiliser, mais j’ai réalisé ensuite qu’il serait encore plus simple de spécifier l’argument directement en ligne de commande (mais je pense que l’option devrait aussi marcher…).
III-D. Maintenir les références sur le PassBuilder et le gestionnaire de Pass▲
Enfin et surtout, vous noterez que j’alloue maintenant les ressources nécessaires à l’optimisation du module IR (IR = Représentation Intermédiaire) sur le tas et non plus sur la pile :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
logDEBUG("Building pass builder.");
passBuilder = std::make_unique<llvm::PassBuilder>();
loopAnalysisManager.reset(new llvm::LoopAnalysisManager(codeGenOptions.DebugPassManager));
functionAnalysisManager.reset(new llvm::FunctionAnalysisManager(codeGenOptions.DebugPassManager));
cGSCCAnalysisManager.reset(new llvm::CGSCCAnalysisManager(codeGenOptions.DebugPassManager));
moduleAnalysisManager.reset(new llvm::ModuleAnalysisManager(codeGenOptions.DebugPassManager));
logDEBUG("Registering passes.");
passBuilder->registerModuleAnalyses(*moduleAnalysisManager);
passBuilder->registerCGSCCAnalyses(*cGSCCAnalysisManager);
passBuilder->registerFunctionAnalyses(*functionAnalysisManager);
passBuilder->registerLoopAnalyses(*loopAnalysisManager);
Malheureusement, il y a une très bonne (ou plutôt une très mauvaise) raison à cela : une chose à laquelle je n’ai pas été très attentif lors de mes premières expériences, c’est qu’il y avait un crash silencieux dans mon programme de test, juste à la sortie de l’appel à la fonction runClang(). Et finalement je l’ai tracé jusqu’à la destruction de l’XXXAnalysisManager (remplacez XXX par Loop/Function/CGSCC/Module). C’est assez simple : je ne pouvais tout simplement pas trouver un moyen de détruire ces ressources proprement après leur allocation. Cela va donc encore plus loin que de simplement les stocker sur le tas, j'ai aussi délibérément laissé des fuites de mémoire, sans essayer de détruire ces objets lors de la destruction de mon objet NervJITImpl :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
NervJITImpl::~NervJITImpl()
{
// Note: the memory for the LLJIT object will leak here because we get a crash when we try to delete it.
std::cout << "Releasing undestructible pointers." << std::endl;
lljit.release();
moduleAnalysisManager.release();
cGSCCAnalysisManager.release();
functionAnalysisManager.release();
loopAnalysisManager.release();
std::cout << "Done releasing undestructible pointers." << std::endl;
}
Comme indiqué ci-dessus, j’ai observé la même chose à propos du pointeur lljit lui-même : je ne peux pas détruire cet objet sans un crash…???? [« Allo Houston… nous avons un problème… »].
D’abord, j’ai pensé que je pouvais faire quelque chose de vraiment faux dans mon propre code, mais en fait j’ai pu reproduire un crash similaire en construisant l’exemple “HowToUseLLJIT” des sources du LLVM. (Notez encore que je construis avec ma configuration CMake personnalisée, c’est peut-être là que je fais quelque chose de faux…) Ensuite, j’ai aussi essayé de construire LLVM en version 10.0.0 plutôt que la version Git courante (11.0.0git), mais j’ai obtenu le même résultat… Donc, n’étant toujours pas sûr de la source du problème et de la manière de le corriger, je vais laisser le code tel quel pour le moment et je reviendrai sur ce problème plus tard.
C’est tout pour l’allocation des ressources : cela n’arrive qu’une fois (lors de la création de l’objet NervJITImpl) et, à partir de là, j’avais bon espoir d’être capable d’utiliser et réutiliser ces ressources pour compiler plusieurs fichiers source C++ en ajoutant de plus en plus de choses au contexte du JIT. Poursuivons notre voyage avec la fonction de construction du module IR.
IV. Construction du module IR et enregistrement de la fonction▲
La fonction principale utilisée pour exécuter la compilation C++ de LLVM IR est la suivante :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
void NervJITImpl::loadModule()
{
if (!compilerInstance->ExecuteAction(*action))
{
logERROR("Cannot execute action with compiler instance!");
}
std::unique_ptr<llvm::Module> module = action->takeModule();
if (!module)
{
logERROR("Cannot retrieve IR module.");
}
// List the functions in the module (before optimizations):
logDEBUG("Module function list: ");
int i=0;
for(auto& f: *module)
{
logDEBUG("func"<<i++<<": '"<<f.getName().str()<<"'");
// We try to demangle the function name here:
// cf. llvm/Demangle/Demangle.h
size_t len = NV_MAX_FUNCTION_NAME_LENGTH;
int status = 0;
char* res = llvm::microsoftDemangle(f.getName().str().c_str(), tmpFuncName, &len, &status, MSDF_NoCallingConvention);
if(res) {
logDEBUG("Function demangled name is: '"<<res<<"'");
// And we map that entry in the function names:
functionNames.insert(std::make_pair<std::string, std::string>(res, f.getName().str()));
}
}
// We run the optimizations:
modulePassManager.run(*module, *moduleAnalysisManager);
auto err = lljit->addIRModule(ThreadSafeModule(std::move(module), *tsContext));
checkLLVMError(std::move(err));
}
D’abord, comme déjà vu plus haut, gardez à l’esprit que je mets à jour la liste frontEndOptions.Inputs juste avant d’appeler cette fonction loadModule(). Ainsi, le compilateur recevra un nouveau fichier source C++ sur lequel travailler.
Ensuite, nous procédons comme suit (en commençant juste comme dans l’article précédent) :
- Nous exécutons l’action de compilation ;
- Puis nous récupérons le Module résultant ;
- Ensuite, j’ai ajouté quelque chose de nouveau ici : je liste les fonctions compilées dans ce nouveau module et, pour chacune d’elles, je fais correspondre le nom de fonction décoré au « nom de fonction un peu dé-décoré ». Je reviendrai sur ce point un peu plus tard (voyez en dessous) ;
- Nous continuons avec les passes d’optimisation en exécutant le modulePassManager sur notre module nouvellement généré ;
- Et nous terminons en ajoutant notre module résultant optimisé à notre JIT (en tant que partie de notre JITDylib principal par défaut).
Nous pourrions techniquement mettre différents modules dans différents JITDylibs, mais je ne suis pas sûr que j’en aurais réellement besoin… à clarifier plus tard
De nouveau, dans le code ci-dessus j’ai utilisé la fonction microsoftDemangle : cette partie doit être adaptée selon l’environnement de développement.
Et c’est tout : si cet appel de fonction se termine correctement, alors ça veut dire que notre code a été compilé et chargé dans la « JIT dynamic library » (« bibliothèque dynamique JIT »), prêt à être récupéré et utilisé ! Et c’est exactement ce que nous faisons dans la section suivante.
V. Récupérer les pointeurs de fonction▲
Pour récupérer une fonction compilée, nous nous basons sur le mécanisme de « recherche de symboles » disponible dans l’objet llvm::orc::LLJIT, mais nous devons tenir compte d’un piège : les noms des fonctions C++ sont « décorés » et nous ne pouvons donc pas récupérer une fonction juste en nous basant sur son nom. C’est là qu’entre en jeu notre génération de correspondance de noms dans l’appel à loadModule() ci-dessus ???? :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
uint64_t NervJITImpl::lookup(const std::string& name)
{
// First we check if we have registered a mangled name for that function:
auto it = functionNames.find(name);
std::string fname;
if(it != functionNames.end()) {
fname = it->second;
logDEBUG("Using mangled name: "<<fname);
}
else {
fname = name;
}
JITEvaluatedSymbol sym = CHECK_LLVM(lljit->lookupLinkerMangled(fname.c_str()));
return sym.getAddress();
}
En réalité, l’objet llvm::orc::LLJIT bénéficie aussi d’un certain support pour récupérer une fonction à partir de son nom non décoré, en utilisant les fonctions mangle() et mangleAndIntern(). Je les ai juste essayées rapidement et ça n’a pas semblé produire le résultat que j’espérais, c’est pourquoi j’ai construit cette table de correspondance par moi-même, mais je devrais sans doute étudier plus longuement comment utiliser ces fonctionnalités de base…
Avec ce code, nous pouvons par exemple demander :
typedef int(*Func)(int, int);
Func add1 = (Func)jit->lookup("int nv_add(int, int)");Et ça fonctionnera ici, même si la fonction nv_add est réellement une fonction C++ (c’est-à-dire, elle n’est pas exportée en tant que fonction C ???? donc son « symbole » ne correspond pas simplement à son nom !)
Maintenant, bien sûr, ce type d’usage est quelque peu limité.
- Vous devez toujours être conscient de la « signature de la fonction » et l’entrer exactement, puisque LLVM dé-décorera son nom. Évidemment, j’ai triché ici et j’ai utilisé les sorties de débogage de loadModule() pour trouver ce que doit être le nom d’entrée que je fournis comme entrée test :
[Debug] func0: '?nv_add@YAHHH@Z'
[Debug] Function demangled name is: 'int nv_add(int, int)'
[Debug] func1: '?nv_sub@@YAHHH@Z'
[Debug] Function demangled name is: 'int nv_sub(int, int)'
[Debug] Before optimization module function list:
[Debug] func0: '?nv_add2@@YAHHH@Z'
[Debug] Function demangled name is: 'int nv_add2(int, int)'
[Debug] func1: '?nv_sub2@@YAHHH@Z'
[Debug] Function demangled name is: 'int nv_sub2(int, int)'Clairement, si vous commencez à utiliser des types même « légèrement plus » complexes, les choses peuvent devenir rapidement, euh, eh bien… beaucoup moins pratiques :
Pourtant, une chose que nous pourrions faire pour gérer ce fouillis serait d’utiliser une sorte de mise en correspondance partielle / d’expression régulière entre le nom calculé de la fonction dé-décorée et une partie de ce nom que nous pourrions fournir comme entrée à la fonction de recherche. Par exemple, nous pourrions nous assurer qu’une entrée comme createClass correspondrait au nom dé-décoré class MyClass * createClass(int) et ainsi trouver le symbole ?createClass@@YAPEAVMyClass@@H@Z. Je ne suis pas sûr que ça en vaille vraiment la peine.
- Dans la plupart des cas, si vous écrivez le code JIT, il est de loin plus facile de juste exporter les fonctions que vous voulez utiliser en tant qu’extern “C”, ce qui vous permet d’éviter complètement le problème de la décoration.
En y réfléchissant, ça peut devenir utile dans une situation où nous devons appeler du code C++ existant sans interface C. Finalement, je devrais considérer ce point plus attentivement : cela pourrait être amusant !
VI. Programme de test mis à jour▲
Donc, finalement, pour m’assurer que cette implémentation du JIT fonctionnait comme attendu, j’ai mis à jour mon programme de test minimal avec le code suivant :
Et ça a marché comme attendu, cool ! ????
Au cas où ce code intéresserait quelqu’un, voici un ZIP contenant tous les fichiers discutés dans leur version courante : nvllvm_20200414.zip.
Les fichiers de ce package ZIP ne compileront pas directement au déballage, bien sûr ! (Je ne partage pas mon projet NervSeed complet ici…) Mais le code fourni peut être utilisé au moins comme un patron.
VII. Étapes suivantes▲
- Clairement, je dois fournir un mécanisme plus flexible de spécification des fichiers d’en-tête avant d’exécuter la compilation.
- Il peut aussi valoir le coup de fournir un support de définition de variables macro (?).
- Je dois penser un peu plus au système de dé-décoration de nom de fonction : je ne suis toujours pas sûr qu’il ait sa place ici ou non.
- Je réfléchis que je devrais peut-être me débarrasser du système PassBuilder/Managers et que je devrais plutôt juste utiliser une implémentation d’un « ancien système de FunctionPassManager » comme décrite ici : https://llvm.org/docs/tutorial/BuildingAJIT2.html (peut-être que de cette manière je me débarrasserais de ces pointeurs que je ne peux pas supprimer pour le moment ?).
VIII. Remerciements Developpez.com▲
Ce tutoriel est la traduction de JIT C++ compiler with LLVM - Part 2. Nous tenons à remercier Thierry Jeanneret pour la traduction, Thibaut Cuvelier pour la relecture technique, Malick pour la mise au gabarit et Claude Leloup pour la relecture orthographique.
