121 lines · plain
1Ok, here are my comments and suggestions about the LLVM instruction set.2We should discuss some now, but can discuss many of them later, when we3revisit synchronization, type inference, and other issues.4(We have discussed some of the comments already.)5 6 7o We should consider eliminating the type annotation in cases where it is8 essentially obvious from the instruction type, e.g., in br, it is obvious9 that the first arg. should be a bool and the other args should be labels:10 11 br bool <cond>, label <iftrue>, label <iffalse>12 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 the cost15 of verbosity. And when the types are obvious from people's experience16 (e.g., in the br instruction), it doesn't seem to help as much.17 18 19o On reflection, I really like your idea of having the two different switch20 types (even though they encode implementation techniques rather than21 semantics). It should simplify building the CFG and my guess is it could22 enable some significant optimizations, though we should think about which.23 24 25o In the lookup-indirect form of the switch, is there a reason not to make26 the val-type uint? Most HLL switch statements (including Java and C++)27 require that anyway. And it would also make the val-type uniform 28 in the two forms of the switch.29 30 I did see the switch-on-bool examples and, while cute, we can just use31 the branch instructions in that particular case.32 33 34o I agree with your comment that we don't need 'neg'.35 36 37o There's a trade-off with the cast instruction:38 + it avoids having to define all the upcasts and downcasts that are39 valid for the operands of each instruction (you probably have thought40 of other benefits also)41 - it could make the bytecode significantly larger because there could42 be a lot of cast operations43 44 45o Making the second arg. to 'shl' a ubyte seems good enough to me.46 255 positions seems adequate for several generations of machines47 and is more compact than uint.48 49 50o I still have some major concerns about including malloc and free in the51 language (either as builtin functions or instructions). LLVM must be52 able to represent code from many different languages. Languages such as53 C, C++ Java and Fortran 90 would not be able to use our malloc anyway54 because each of them will want to provide a library implementation of it.55 56 This gets even worse when code from different languages is linked57 into a single executable (which is fairly common in large apps).58 Having a single malloc would just not suffice, and instead would simply59 complicate the picture further because it adds an extra variant in60 addition to the one each language provides.61 62 Instead, providing a default library version of malloc and free63 (and perhaps a malloc_gc with garbage collection instead of free)64 would make a good implementation available to anyone who wants it.65 66 I don't recall all your arguments in favor so let's discuss this again,67 and soon.68 69 70o 'alloca' on the other hand sounds like a good idea, and the71 implementation seems fairly language-independent so it doesn't have the72 problems with malloc listed above.73 74 75o About indirect call:76 Your option #2 sounded good to me. I'm not sure I understand your77 concern about an explicit 'icall' instruction?78 79 80o A pair of important synchronization instr'ns to think about:81 load-linked82 store-conditional83 84 85o Other classes of instructions that are valuable for pipeline performance:86 conditional-move 87 predicated instructions88 89 90o I believe tail calls are relatively easy to identify; do you know why91 .NET has a tailcall instruction?92 93 94o I agree that we need a static data space. Otherwise, emulating global95 data gets unnecessarily complex.96 97 98o About explicit parallelism:99 100 We once talked about adding a symbolic thread-id field to each101 instruction. (It could be optional so single-threaded codes are102 not penalized.) This could map well to multi-threaded architectures103 while providing easy ILP for single-threaded onces. But it is probably104 too radical an idea to include in a base version of LLVM. Instead, it105 could a great topic for a separate study.106 107 What is the semantics of the IA64 stop bit?108 109 110 111 112o And finally, another thought about the syntax for arrays :-)113 114 Although this syntax:115 array <dimension-list> of <type>116 is verbose, it will be used only in the human-readable assembly code so117 size should not matter. I think we should consider it because I find it118 to be the clearest syntax. It could even make arrays of function119 pointers somewhat readable.120 121