On Fri, 2 Dec 2005, Andrew Lenharth wrote:> 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 :)
:)
-Chris
--
http://nondot.org/sabre/
http://llvm.org/