[LLVMdev] Re: LLVM Compiler Infrastructure Tutorial

[Misha Brukman]

On Wed, Oct 20, 2004 at 11:59:45AM -0700, Yiping Fan wrote:
> Yeah. We need to have more extra fields in the instruction. Fo
> example, during high-level synthesis, we must schedule an instruction
> to a certain control step (or cycle), and bind it to be execute on a
> certain functional unit, etc.  

Since we're talking about "execution" and "scheduling", you are creating
a back-end for LLVM, correct?  In that case, we're talking about code
generation.

LLVM is a target-independent representation.  Note that with LLVM, we
are trying to separate WHAT the program is doing (the meaning of the
program) from HOW it does it (which specific instructions get executed
and when, and this includes scheduling).  What you are trying to add to
it is target-dependent (e.g. scheduling).  That is not advisable on
several levels, one of which is breaking the target abstraction that we
have tried hard to maintain.  

Take a look at the X86, PowerPC, and Sparc target code generators
(llvm/lib/Target/*).  They are using a different representation,
specifically, MachineInstr, MachineBasicBlock, and MachineFunction
classes that are target-dependent (for example, they include asm opcodes
and target registers).  Something target-dependent such as scheduling
and assignment to functional units would be done in this representation,
after code generation (LLVM -> Machine code).

Presumably, this (e.g. scheduling) information is not provided from the
C/C++ front-end, but computed by a pass that you would write, correct?
Then you can always compute this information on the fly, before any pass
that needs to do something with this information needs to use it.  As
Reid mentioned, take a look a the Analysis interfaces and see if you can
implement this as an Analysis that could be required by a pass and
transparently ran for you by the PassManager.

> Besides the in-memory exchange of the information, we also want
> on-disk exchange. That introduces the write-out/parse-in problem.

Again, if this is information that's computable from bytecode alone, you
do not need to store it every time -- an Analyser pass can compute it
dynamically.  Also, as a reminder, if you change the LLVM
representation, your new version may or may not be able to use the
current set of analyses and optimizations, thus forcing you to
"reinvent the wheel" in that respect.

-- 
Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu