RFC: Plugable intrinsics

I can think of many people that use LLVM and maintain out of tree
extentions that will likely never be incorporated into mainline.
Maintaining out of tree intrnisics takes a fair amount of work and leads
to the choice of using a single version of LLVM for a project (and thus
have to manually incorporate bug fixes) or risk untimely breakage. I
propose that the plugin be extended to allow plugable intrinsics. To be
sucessful, such a plugin will have to provide hooks for basic AA
information, DAG supoort and legalization, and code generation for some
architectures.

Any of the places that currently handle intrisics would have to be
modified to check loaded libraries for all registered external
intrinsics rather than failing on unknown intrinsics. This souldn't
slow the processing of builtin intrinsics.

This is the high level idea. I have more concrete implementation ideas,
but this should suffice for purposes of initial discussion. I think
this would greatly reduce the burdon of using LLVM in smaller context
like research and make it much easier to try out extentions before
considering them for inclusion in LLVM.

I have talked to several people (both in my group and out) who maintain
out of tree intrinsics and they univerally think this would be a good
idea :slight_smile:

I can think of many people that use LLVM and maintain out of tree
extentions that will likely never be incorporated into mainline.
Maintaining out of tree intrnisics takes a fair amount of work and leads
to the choice of using a single version of LLVM for a project (and thus
have to manually incorporate bug fixes) or risk untimely breakage. I
propose that the plugin be extended to allow plugable intrinsics. To be
sucessful, such a plugin will have to provide hooks for basic AA
information, DAG supoort and legalization, and code generation for some
architectures.

I completely agree that this would be a great thing to have. There are some logistical things that might come up though. I'm confident that we can work through these though... if you'd like to draft up some sort of mini proposal that outlines your thoughts more concretely, we can work on it and figure it out. I'm not looking for anything fancy or formal here, maybe something like the notes I have on my llvmnotes page.

One particular detail is that an intrinsic needs implement pieces of the code generator (among other things). If the plugin uses the codegen API's, it will require anything that uses the plugin to have the codegen library linked in, which is currently not the case for tools like opt or gccas.

Another thing is that some intrinsics are target-specific. We want the intrinsic to have some default behavior (e.g. expand into an abort, be ignored, default to 0, etc) on targets that don't support it, but have useful behavior on the targets that do support it. If an intrinsic has special support for Alpha though, don't want it to depend on the alpha backend to be linked into llc...

Any of the places that currently handle intrisics would have to be
modified to check loaded libraries for all registered external
intrinsics rather than failing on unknown intrinsics. This souldn't
slow the processing of builtin intrinsics.

Makes total sense. If done well, we should be able to move some of the less common intrinsics (read/write port, etc) to use the plugin api. Done REALLY well, we should be able to move them all to use it, which I think would be wonderful.

This is the high level idea. I have more concrete implementation ideas,
but this should suffice for purposes of initial discussion. I think
this would greatly reduce the burdon of using LLVM in smaller context
like research and make it much easier to try out extentions before
considering them for inclusion in LLVM.

Certainly!

I have talked to several people (both in my group and out) who maintain
out of tree intrinsics and they univerally think this would be a good
idea :slight_smile:

:slight_smile:

-Chris