[LLVMdev] Re: LLVM Compiler Infrastructure Tutorial

[Reid Spencer]

Yiping,

The LLVM IR is a mid-level representation and it is inadvisable to alter the 
definition of an instruction.  What you're trying to do seems to be related to 
code generation (scheduling and binding to a functional unit).  So, I would 
suggest that you write an analysis pass to compute and provide the information 
you need out of band. Then, you will need to provide a code generation pass to 
use the analysis information you generated to provide the necessary scheduling 
and functional unit affinity.  I believe this approach will allow existing 
transforms and analyses to continue to work while providing you with the 
information you need.

You should review the code in the Analysis library to get examples of how to 
write a function pass and associate it with instructions. If you need to store 
this information with the bytecode (ill advised), the bcreader and bcwriter 
libraries could be augmented to also store your computed information.

Without more details on what you're trying to accomplish (the ultimate goal), 
its hard to be more specific about what you need to do.

Reid.

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.
> 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
>>
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>