246 lines · plain
1From: Chris Lattner <sabre@nondot.org>2To: "Vikram S. Adve" <vadve@cs.uiuc.edu>3Subject: Re: LLVM Feedback4 5I've included your feedback in the /home/vadve/lattner/llvm/docs directory6so that it will live in CVS eventually with the rest of LLVM. I've7significantly updated the documentation to reflect the changes you8suggested, as specified below:9 10> We should consider eliminating the type annotation in cases where it is11> essentially obvious from the instruction type:12> br bool <cond>, label <iftrue>, label <iffalse>13> I think your point was that making all types explicit improves clarity14> and readability. I agree to some extent, but it also comes at the15> cost of verbosity. And when the types are obvious from people's16> experience (e.g., in the br instruction), it doesn't seem to help as17> much.18 19Very true. We should discuss this more, but my reasoning is more of a20consistency argument. There are VERY few instructions that can have all21of the types eliminated, and doing so when available unnecessarily makes22the language more difficult to handle. Especially when you see 'int23%this' and 'bool %that' all over the place, I think it would be24disorienting to see:25 26 br %predicate, %iftrue, %iffalse27 28for branches. Even just typing that once gives me the creeps. ;) Like I29said, we should probably discuss this further in person...30 31> On reflection, I really like your idea of having the two different32> switch types (even though they encode implementation techniques rather33> than semantics). It should simplify building the CFG and my guess is it34> could enable some significant optimizations, though we should think35> about which.36 37Great. I added a note to the switch section commenting on how the VM38should just use the instruction type as a hint, and that the39implementation may choose altermate representations (such as predicated40branches).41 42> In the lookup-indirect form of the switch, is there a reason not to43> make the val-type uint?44 45No. This was something I was debating for a while, and didn't really feel46strongly about either way. It is common to switch on other types in HLL's47(for example signed int's are particularly common), but in this case, all48that will be added is an additional 'cast' instruction. I removed that49from the spec.50 51> I agree with your comment that we don't need 'neg'52 53Removed.54 55> There's a trade-off with the cast instruction:56> + it avoids having to define all the upcasts and downcasts that are57> valid for the operands of each instruction (you probably have58> thought of other benefits also)59> - it could make the bytecode significantly larger because there could60> be a lot of cast operations61 62 + You NEED casts to represent things like:63 void foo(float);64 ...65 int x;66 ...67 foo(x);68 in a language like C. Even in a Java like language, you need upcasts69 and some way to implement dynamic downcasts.70 + Not all forms of instructions take every type (for example you can't71 shift by a floating point number of bits), thus SOME programs will need72 implicit casts.73 74To be efficient and to avoid your '-' point above, we just have to be75careful to specify that the instructions shall operate on all common76types, therefore casting should be relatively uncommon. For example all77of the arithmetic operations work on almost all data types.78 79> Making the second arg. to 'shl' a ubyte seems good enough to me.80> 255 positions seems adequate for several generations of machines81 82Okay, that comment is removed.83 84> and is more compact than uint.85 86No, it isn't. Remember that the bytecode encoding saves value slots into87the bytecode instructions themselves, not constant values. This is88another case where we may introduce more cast instructions (but we will89also reduce the number of opcode variants that must be supported by a90virtual machine). Because most shifts are by constant values, I don't91think that we'll have to cast many shifts. :)92 93> I still have some major concerns about including malloc and free in the94> language (either as builtin functions or instructions).95 96Agreed. How about this proposal:97 98malloc/free are either built in functions or actual opcodes. They provide99all of the type safety that the document would indicate, blah blah100blah. :)101 102Now, because of all of the excellent points that you raised, an103implementation may want to override the default malloc/free behavior of104the program. To do this, they simply implement a "malloc" and105"free" function. The virtual machine will then be defined to use the user106defined malloc/free function (which return/take void*'s, not type'd107pointers like the builtin function would) if one is available, otherwise108fall back on a system malloc/free.109 110Does this sound like a good compromise? It would give us all of the111typesafety/elegance in the language while still allowing the user to do112all the cool stuff they want to...113 114> 'alloca' on the other hand sounds like a good idea, and the115> implementation seems fairly language-independent so it doesn't have the116> problems with malloc listed above.117 118Okay, once we get the above stuff figured out, I'll put it all in the119spec.120 121> About indirect call:122> Your option #2 sounded good to me. I'm not sure I understand your123> concern about an explicit 'icall' instruction?124 125I worry too much. :) The other alternative has been removed. 'icall' is126now up in the instruction list next to 'call'.127 128> I believe tail calls are relatively easy to identify; do you know why129> .NET has a tailcall instruction?130 131Although I am just guessing, I believe it probably has to do with the fact132that they want languages like Haskell and lisp to be efficiently runnable133on their VM. Of course this means that the VM MUST implement tail calls134'correctly', or else life will suck. :) I would put this into a future135feature bin, because it could be pretty handy...136 137> A pair of important synchronization instr'ns to think about:138> load-linked139> store-conditional140 141What is 'load-linked'? I think that (at least for now) I should add these142to the 'possible extensions' section, because they are not immediately143needed...144 145> Other classes of instructions that are valuable for pipeline146> performance:147> conditional-move 148> predicated instructions149 150Conditional move is effectly a special case of a predicated151instruction... and I think that all predicated instructions can possibly152be implemented later in LLVM. It would significantly change things, and153it doesn't seem to be very necessary right now. It would seem to154complicate flow control analysis a LOT in the virtual machine. I would155tend to prefer that a predicated architecture like IA64 convert from a156"basic block" representation to a predicated rep as part of it's dynamic157complication phase. Also, if a basic block contains ONLY a move, then158that can be trivally translated into a conditional move...159 160> I agree that we need a static data space. Otherwise, emulating global161> data gets unnecessarily complex.162 163Definitely. Also a later item though. :)164 165> We once talked about adding a symbolic thread-id field to each166> ..167> Instead, it could a great topic for a separate study.168 169Agreed. :)170 171> What is the semantics of the IA64 stop bit?172 173Basically, the IA64 writes instructions like this:174mov ...175add ...176sub ...177op xxx178op xxx179;;180mov ...181add ...182sub ...183op xxx184op xxx185;;186 187Where the ;; delimits a group of instruction with no dependencies between188them, which can all be executed concurrently (to the limits of the189available functional units). The ;; gets translated into a bit set in one190of the opcodes.191 192The advantages of this representation is that you don't have to do some193kind of 'thread id scheduling' pass by having to specify ahead of time how194many threads to use, and the representation doesn't have a per instruction195overhead...196 197> And finally, another thought about the syntax for arrays :-)198> Although this syntax:199> array <dimension-list> of <type>200> is verbose, it will be used only in the human-readable assembly code so201> size should not matter. I think we should consider it because I find it202> to be the clearest syntax. It could even make arrays of function203> pointers somewhat readable.204 205My only comment will be to give you an example of why this is a bad206idea. :)207 208Here is an example of using the switch statement (with my recommended209syntax):210 211switch uint %val, label %otherwise, 212 [%3 x {uint, label}] [ { uint %57, label %l1 }, 213 { uint %20, label %l2 }, 214 { uint %14, label %l3 } ]215 216Here it is with the syntax you are proposing:217 218switch uint %val, label %otherwise, 219 array %3 of {uint, label} 220 array of {uint, label}221 { uint %57, label %l1 },222 { uint %20, label %l2 },223 { uint %14, label %l3 }224 225Which is ambiguous and very verbose. It would be possible to specify226constants with [] brackets as in my syntax, which would look like this:227 228switch uint %val, label %otherwise,229 array %3 of {uint, label} [ { uint %57, label %l1 },230 { uint %20, label %l2 },231 { uint %14, label %l3 } ]232 233But then the syntax is inconsistent between type definition and constant234definition (why do []'s enclose the constants but not the types??). 235 236Anyways, I'm sure that there is much debate still to be had over237this... :)238 239-Chris240 241http://www.nondot.org/~sabre/os/242http://www.nondot.org/MagicStats/243http://korbit.sourceforge.net/244 245 246