//
// This file contains random notes and points of interest about the X86 backend.
//
-// Snippets of this document will probably become the final report for CS497
-//
//===----------------------------------------------------------------------===//
===========
specify a destination register to the BuildMI call.
-=======================
-III. Source Code Layout
-=======================
+======================
+IV. Source Code Layout
+======================
The LLVM-JIT is composed of source files primarily in the following locations:
lib/CodeGen
-----------
-This directory will contain all of the target independant transformations (for
+This directory will contain all of the target independent transformations (for
example, register allocation) that we write. These transformations should only
use information exposed through the Target interface, they should not include
any target specific header files.
lib/Target/X86
--------------
This directory contains the machine description for X86 that is required to the
-rest of the compiler working. It contains any code that is truely specific to
+rest of the compiler working. It contains any code that is truly specific to
the X86 backend, for example the instruction selector and machine code emitter.
-tools/jello
------------
+tools/lli/JIT
+-------------
This directory contains the top-level code for the JIT compiler. This code
basically boils down to a call to TargetMachine::addPassesToJITCompile. As we
progress with the project, this will also contain the compile-dispatch-recompile
test/Regression/Jello
---------------------
-This directory contains regression tests for the JIT. Initially it contains a
-bunch of really trivial testcases that we should build up to supporting.
+This directory contains regression tests for the JIT.
-===================================================
-IV. Strange Things, or, Things That Should Be Known
-===================================================
+==================================================
+V. Strange Things, or, Things That Should Be Known
+==================================================
Representing memory in MachineInstrs
------------------------------------
==========================
-V. TODO / Future Projects
+VI. TODO / Future Projects
==========================
There are a large number of things remaining to do. Here is a partial list:
-Critial path:
--------------
-
-0. Finish providing SSA form. This involves keeping track of some information
- when instructions are added to the function, but should not affect that API
- for creating new MInstructions or adding them to the program.
-1. Finish dumb instruction selector
-2. Write dumb register allocator
-3. Write assembly language emitter
-4. Write machine code emitter
-
Next Phase:
-----------
1. Implement linear time optimal instruction selector
After this project:
-------------------
1. Implement lots of nifty runtime optimizations
-2. Implement a static compiler backend for x86 (might come almost for free...)
-3. Implement new spiffy targets: IA64? X86-64? M68k? Who knows...
+2. Implement new targets: IA64? X86-64? M68k? MMIX? Who knows...
Infrastructure Improvements:
----------------------------
bytecode without having to read the whole program. Bytecode reader should be
extended to allow on-demand loading of functions.
-2. PassManager needs to be able to run just a single function through a pipeline
- of FunctionPass's.
-
-3. llvmgcc needs to be modified to output 32-bit little endian LLVM files.
- Preferably it will be parameterizable so that multiple binaries need not
- exist. Until this happens, we will be restricted to using type safe
- programs (most of the Olden suite and many smaller tests), which should be
- sufficient for our 497 project. Additionally there are a few places in the
- LLVM infrastructure where we assume Sparc TargetData layout. These should
- be easy to factor out and identify though.
+2. X86/Printer.cpp and Sparc/EmitAssembly.cpp both have copies of what is
+ roughly the same code, used to output constants in a form the assembler
+ can understand. These functions should be shared at some point. They
+ should be rewritten to pass around iostreams instead of strings. The
+ list of functions is as follows:
+
+ isStringCompatible
+ toOctal
+ ConstantExprToString
+ valToExprString
+ getAsCString
+ printSingleConstantValue (with TypeToDataDirective inlined)
+ printConstantValueOnly