[LLVMdev] Re: LLVM Compiler Infrastructure Tutorial

[Yiping Fan]

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.
Besides the in-memory exchange of the information, we also want on-disk
exchange. That introduces the write-out/parse-in problem.

Thanks

----- Original Message ----- 
From: "Misha Brukman" <brukman at uiuc.edu>
To: "Yiping Fan" <fanyp at CS.UCLA.EDU>; "'Zhiru Zhang'" <zhiruz at CS.UCLA.EDU>; 
"Guoling Han" <leohgl at CS.UCLA.EDU>
Cc: <llvmdev at cs.uiuc.edu>
Sent: Wednesday, October 20, 2004 11:43 AM
Subject: Re: LLVM Compiler Infrastructure Tutorial


> I'm CC'ing the llvm-dev list because other people are more knowledgeable
> about the bytecode format/encoding than I am.  Please follow-up the
> replies to the list.
>
> On Wed, Oct 20, 2004 at 11:27:53AM -0700, Yiping Fan wrote:
>> We also want to extend the llvm instructions/intrinsic
>> functions/types/passes to support our high-level synthesis for
>> hardware.  First of all, we want to enhance the Bytecode/Asm Writer
>> and reader to support many attributes for every instruction, basic
>> block, function, and module.  Basically, we want many extra fields to
>> be written out and read in. However, I cannot find a obvious way to do
>> this in current LLVM. Do you have any suggestion about this?
>
> We have a document describing the bytecode format here:
>  [1] http://llvm.cs.uiuc.edu/docs/BytecodeFormat.html
> Also, a document on how to add new instructions, intrinsic functions:
>  [2] http://llvm.cs.uiuc.edu/docs/ExtendingLLVM.html
> ([2] isn't exactly what you're asking for, but related)
>
> The question is, do you really want to have more extra fields in the
> instructions?  What is it that you need to represent that the current
> system does not allow you to do?
>
> If you want multiple passes to communicate some information about the
> LLVM bytecode, perhaps it is better to keep a map/vector/etc on the side
> for this "side-band" information?
>
> You should realize that as soon as you change instructions and/or their
> meaning, you may prevent the current set of analyzers and optimizations
> from working as they do now.
>
> -- 
> Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
>