<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2523" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Vikram, <BR> I also agree with
you. I understand that target-independent </FONT><FONT face=Arial
size=2>representation is very valuable </FONT></DIV>
<DIV><FONT face=Arial size=2>and important for software
compilation. <BR></FONT></DIV>
<DIV><FONT face=Arial size=2> However, when we are
doing high-level synthesis (also called behavioral/architectural
synthesis), <BR>the targeting architecture is also changing. That is, we need to
do architecture exploration </FONT></DIV>
<DIV><FONT face=Arial size=2>and the IR transfromation simultaneously. For
example, after a particular pass, we may need 4 </FONT></DIV>
<DIV><FONT face=Arial size=2>ALUs to execute </FONT><FONT face=Arial
size=2>the program, under a certain latency constraint</FONT><FONT
face=Arial size=2>; then, after another optimization pass, </FONT></DIV>
<DIV><FONT face=Arial size=2>we may end up with only 3 ALUs. The
instruction-to-ALU binding will be different after this pass. </FONT></DIV>
<DIV><FONT face=Arial size=2>The samething could happen for register
allocation and binding, and other synthesis pass. </FONT></DIV>
<DIV><FONT face=Arial size=2> Also, there are lots of
synthesis passes there, such as scheduling, functional unit binding,
</FONT></DIV>
<DIV><FONT face=Arial size=2>register binding, </FONT><FONT face=Arial
size=2>(FU) port binding, re-scheduling and re-binding,
interconnect reduction, DSP </FONT></DIV>
<DIV><FONT face=Arial size=2>specific </FONT><FONT face=Arial
size=2>optimization, ...</FONT></DIV>
<DIV><FONT face=Arial size=2> Therefore, we need some
architectural information (both on-disk and in-memory) associated with
</FONT></DIV>
<DIV><FONT face=Arial size=2>the instructions after every </FONT><FONT
face=Arial size=2>synthesis </FONT><FONT face=Arial size=2>pass. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> In addition, in hardware
description, there are lots of bit-vector manipulations (e.g., bit
extraction,</FONT></DIV>
<DIV><FONT face=Arial size=2>concatenatoin ...), which are not represented
</FONT><FONT face=Arial size=2>in LLVM. We are thinking about to add some
intrinsic </FONT></DIV>
<DIV><FONT face=Arial size=2>functions to LLVM, so that the original instruction
set can be untouched. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> Currently we use a simple CDFG (CFG,
whose every node is a DFG) representation to do our </FONT></DIV>
<DIV><FONT face=Arial size=2>synthesis. Of cource, it is not as powerful as
LLVM, and we also want to use many of your </FONT></DIV>
<DIV><FONT face=Arial size=2>transformation/analysis passes. That is why we want
to move our project on top of your IR. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Thanks,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>-Yiping</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2> </DIV></FONT>
<BLOCKQUOTE dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=vadve@cs.uiuc.edu href="mailto:vadve@cs.uiuc.edu">Vikram Adve</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=llvmdev@cs.uiuc.edu
href="mailto:llvmdev@cs.uiuc.edu">LLVM Developers Mailing List</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=zhiruz@CS.UCLA.EDU
href="mailto:zhiruz@CS.UCLA.EDU">'Zhiru Zhang'</A> ; <A
title=leohgl@CS.UCLA.EDU href="mailto:leohgl@CS.UCLA.EDU">Guoling Han</A> ; <A
title=fanyp@CS.UCLA.EDU href="mailto:fanyp@CS.UCLA.EDU">Yiping Fan</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, October 20, 2004 3:08
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [LLVMdev] Re: LLVM Compiler
Infrastructure Tutorial</DIV>
<DIV><BR></DIV>Yiping,<BR><BR>Could you describe in a little more detail what
your goals are? I agree with Reid and Misha that modifying the instruction
definition is usually not advisable but to suggest alternatives, we would need
to know more. Also, for some projects it could make sense to change the
instruction set.<BR><BR><?x-tad-bigger>--Vikram<BR><A
href="http://www.cs.uiuc.edu/~vadve">http://www.cs.uiuc.edu/~vadve</A><BR><A
href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu/</A><BR><?/x-tad-bigger><BR>On
Oct 20, 2004, at 2:41 PM, Misha Brukman wrote:<BR><BR>
<BLOCKQUOTE>On Wed, Oct 20, 2004 at 11:59:45AM -0700, Yiping Fan wrote:<BR>
<BLOCKQUOTE>Yeah. We need to have more extra fields in the instruction.
Fo<BR>example, during high-level synthesis, we must schedule an
instruction<BR>to a certain control step (or cycle), and bind it to be
execute on a<BR>certain functional unit, etc. <BR></BLOCKQUOTE><BR>Since
we're talking about "execution" and "scheduling", you are creating<BR>a
back-end for LLVM, correct? In that case, we're talking about
code<BR>generation.<BR><BR>LLVM is a target-independent representation. Note
that with LLVM, we<BR>are trying to separate WHAT the program is doing (the
meaning of the<BR>program) from HOW it does it (which specific instructions
get executed<BR>and when, and this includes scheduling). What you are trying
to add to<BR>it is target-dependent (e.g. scheduling). That is not advisable
on<BR>several levels, one of which is breaking the target abstraction that
we<BR>have tried hard to maintain. <BR><BR>Take a look at the X86, PowerPC,
and Sparc target code generators<BR>(llvm/lib/Target/*). They are using a
different representation,<BR>specifically, MachineInstr, MachineBasicBlock,
and MachineFunction<BR>classes that are target-dependent (for example, they
include asm opcodes<BR>and target registers). Something target-dependent
such as scheduling<BR>and assignment to functional units would be done in
this representation,<BR>after code generation (LLVM -> Machine
code).<BR><BR>Presumably, this (e.g. scheduling) information is not provided
from the<BR>C/C++ front-end, but computed by a pass that you would write,
correct?<BR>Then you can always compute this information on the fly, before
any pass<BR>that needs to do something with this information needs to use
it. As<BR>Reid mentioned, take a look a the Analysis interfaces and see if
you can<BR>implement this as an Analysis that could be required by a pass
and<BR>transparently ran for you by the PassManager.<BR><BR>
<BLOCKQUOTE>Besides the in-memory exchange of the information, we also
want<BR>on-disk exchange. That introduces the write-out/parse-in
problem.<BR></BLOCKQUOTE><BR>Again, if this is information that's computable
from bytecode alone, you<BR>do not need to store it every time -- an
Analyser pass can compute it<BR>dynamically. Also, as a reminder, if you
change the LLVM<BR>representation, your new version may or may not be able
to use the<BR>current set of analyses and optimizations, thus forcing you
to<BR>"reinvent the wheel" in that respect.<BR><BR>-- <BR>Misha Brukman ::
http://misha.brukman.net ::
http://llvm.cs.uiuc.edu<BR><BR>_______________________________________________<BR>LLVM
Developers mailing list<BR>LLVMdev@cs.uiuc.edu
http://llvm.cs.uiuc.edu<BR>http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev<BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>