Difference between revisions of "NaplesPU LLVM Documentation"

Revision as of 18:47, 30 March 2019

The main task of the backend is to generate nu+ assembly code from the LLVM IR obtained by the Clang frontend. It also handles object representation of classes needed to create the assembler and the disassembler. The nu+ backend is contained in the NuPlus folder under "compiler/lib/Target" directory. It contains several files, each implementing a specific class of the LLVM Framework.

An LLVM backend is constructed on two types of file, C++ and TableGen source files. Refer to section TableGen to get a detailed explanation of the latters.

Required reading

Before working on LLVM, you should be familiar with some things. In particular:

1. Basic Blocks
2. SSA (Static Single Assignment) form
3. AST (Abstract Syntax tree)
4. DAG Direct Acyclic Graph.

In addition to general aspects about compilers, it is recommended to review the following topics:

1. LLVM architecture
2. LLVM Intermediate Representation

See the following textbook for other information Getting Started with LLVM Core Libraries and LLVM Cookbook.

See also this article to get an overview of the main CodeGenerator phases.

TableGen

TableGen is a record-oriented language used to describe the target-specific information. It is written by the LLVM team in order to simplify the back-end development and to avoid potential code redundancy. For example, by using TableGen, if some feature of the target-specific register file changes, you do not need to modify different files wherever the register appears but you need only to modify the .td file that contains its definition. Actually, the TableGen is used to define instruction formats, instructions, registers, pattern-matching DAGs, instruction selection matching order, calling conventions, and target platform properties.

For other informations, check the TableGen Documentation

Backend Description

This section shows how is implemented the backend support for nu+ within LLVM.

Target Definition

The target-specific information is explained in TableGen files. The custom target is defined by creating a new NuPlus.td file, in which the target itself is described. This file contains the implementation of the target-independent interfaces provided by \texttt{Target.td}. Implementations are done by using the class inheritance mechanism.

The code showed in the figure \ref{code:nuplustdtarget} is the \texttt{Target} class definition that should be implemented in \texttt{<TargetName>.td}.

\begin{figure}[!htbp] \begin{lstlisting} class Target {

 InstrInfo InstructionSet;
 list<AsmParser> AssemblyParsers = [DefaultAsmParser];
 list<AsmParserVariant> AssemblyParserVariants = [DefaultAsmParserVariant];
 list<AsmWriter> AssemblyWriters = [DefaultAsmWriter];

} \end{lstlisting} \caption{\texttt{Target} class definition in \texttt{Target.td}} \label{code:nuplustdtarget} \end{figure}

This file should also include the other defined \texttt{.td} target-related files. It is required to define the target features by adding the following line: \begin{verbatim} def : Processor<"mytarget", NoItineraries, []>; \end{verbatim} \texttt{Processor} is a class defined in \texttt{Target.td} as follows: \begin{verbatim} class Processor<string n, ProcessorItineraries pi,

    				          list<SubtargetFeature> f>

\end{verbatim} where: \begin{itemize} \item \texttt{n} is the chipset name, used in the command line option \texttt{-mcpu} to determine the appropriate chip. \item \texttt{pi} is the processor itinerary, as described in the theoretical description of the LLVM \textit{instruction scheduling }phase. \texttt{NoItinerary} means that no itinerary is defined. \item \texttt{f} is a list of target features. \end{itemize}