I want to implement a new intrinsic in llvm that will denote a
parallel section within a function. I followed the documentation for
extending llvm (http://llvm.org/docs/ExtendingLLVM.html) but there is
something about the working mechanism that is not clear for me.
1. Why do we have to add support for the C backend?
Because it is an important part of LLVM. For example, bugpoint uses the
CBE as a reference code generator. If you break CBE, you break bugpoint.
If you break bugpoint, we will have a much harder time finding bugs in
LLC, LLI, and JIT. The CBE is just as important a code generator as any
of the targets. For example, it would be a vital component of
bootstrapping LLVM onto a platform that had no C++ compiler.
Is this only
necessary to transform the llvm assembly (bytecode) into C code by
using the library APIs?
I'm not sure what you mean by "by using the library APIs", but yes,
that's the basic idea. The CBE takes an LLVM Module (in C++ IR form) and
generates C code that will execute the represented program. It is
necessary for your intrinsic to be supported in the CBE.
2. Is the support that we add for the specific target the one that
takes part in generating the target specific code (native) from the
There are two parts to this. First, you must lower the intrinsic from
its IR form (a Function*) into a SelectionDAG node. This is done in
SelectionDAGISel.cpp in the visitIntrinsicCall method. You might need to
change DAGCombiner.cpp and LegalizeDAG.cpp depending on the intrinsic
and its lowering. The second part is to modify the targets or generic
code gen to handle the lowered intrinsic call. This part is target
3. Can I introduce an intrinsic that is actually a call to my function
that implements the logic? I suppose it is possible but unfortunately
I couldn't figure it out. For example, in GCC we can write an
intrinsic that translates to a C code.
As part of PR1297 (http://llvm.org/PR1297) I am about to make this
happen. There are certain kinds of intrinsics that want to have a
function body generated for them if a target or code generator cannot
handle the intrinsic natively. For example, the company I work for has
targets that know how to do a "bit_concat". That is, take two integers
of any width and concatenate them into a longer integer. Most other
targets, however, don't know how to do this natively. In such cases the
intrinsic for "bit_concat" is lowered to an internal function that does
the necessary shift/or implementation.
I expect this functionality to be incorporated into LLVM in the next
week or so. Watch for changes to lib/CodeGen/IntrinsicLowering.cpp