From 68cb31901c590cabceee6e6356d62c84142114cb Mon Sep 17 00:00:00 2001 From: mike-m Date: Thu, 6 May 2010 23:45:43 +0000 Subject: Overhauled llvm/clang docs builds. Closes PR6613. NOTE: 2nd part changeset for cfe trunk to follow. *** PRE-PATCH ISSUES ADDRESSED - clang api docs fail build from objdir - clang/llvm api docs collide in install PREFIX/ - clang/llvm main docs collide in install - clang/llvm main docs have full of hard coded destination assumptions and make use of absolute root in static html files; namely CommandGuide tools hard codes a website destination for cross references and some html cross references assume website root paths *** IMPROVEMENTS - bumped Doxygen from 1.4.x -> 1.6.3 - splits llvm/clang docs into 'main' and 'api' (doxygen) build trees - provide consistent, reliable doc builds for both main+api docs - support buid vs. install vs. website intentions - support objdir builds - document targets with 'make help' - correct clean and uninstall operations - use recursive dir delete only where absolutely necessary - added call function fn.RMRF which safeguards against botched 'rm -rf'; if any target (or any variable is evaluated) which attempts to remove any dirs which match a hard-coded 'safelist', a verbose error will be printed and make will error-stop. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103213 91177308-0d34-0410-b5e6-96231b3b80d8 --- .../2000-11-18-EarlyDesignIdeasResp.txt | 199 --------------------- 1 file changed, 199 deletions(-) delete mode 100644 docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt (limited to 'docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt') diff --git a/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt b/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt deleted file mode 100644 index 1c725f5aa7..0000000000 --- a/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt +++ /dev/null @@ -1,199 +0,0 @@ -Date: Sun, 19 Nov 2000 16:23:57 -0600 (CST) -From: Chris Lattner -To: Vikram Adve -Subject: Re: a few thoughts - -Okay... here are a few of my thoughts on this (it's good to know that we -think so alike!): - -> 1. We need to be clear on our goals for the VM. Do we want to emphasize -> portability and safety like the Java VM? Or shall we focus on the -> architecture interface first (i.e., consider the code generation and -> processor issues), since the architecture interface question is also -> important for portable Java-type VMs? - -I forsee the architecture looking kinda like this: (which is completely -subject to change) - -1. The VM code is NOT guaranteed safe in a java sense. Doing so makes it - basically impossible to support C like languages. Besides that, - certifying a register based language as safe at run time would be a - pretty expensive operation to have to do. Additionally, we would like - to be able to statically eliminate many bounds checks in Java - programs... for example. - - 2. Instead, we can do the following (eventually): - * Java bytecode is used as our "safe" representation (to avoid - reinventing something that we don't add much value to). When the - user chooses to execute Java bytecodes directly (ie, not - precompiled) the runtime compiler can do some very simple - transformations (JIT style) to convert it into valid input for our - VM. Performance is not wonderful, but it works right. - * The file is scheduled to be compiled (rigorously) at a later - time. This could be done by some background process or by a second - processor in the system during idle time or something... - * To keep things "safe" ie to enforce a sandbox on Java/foreign code, - we could sign the generated VM code with a host specific private - key. Then before the code is executed/loaded, we can check to see if - the trusted compiler generated the code. This would be much quicker - than having to validate consistency (especially if bounds checks have - been removed, for example) - -> This is important because the audiences for these two goals are very -> different. Architects and many compiler people care much more about -> the second question. The Java compiler and OS community care much more -> about the first one. - -3. By focusing on a more low level virtual machine, we have much more room - for value add. The nice safe "sandbox" VM can be provided as a layer - on top of it. It also lets us focus on the more interesting compilers - related projects. - -> 2. Design issues to consider (an initial list that we should continue -> to modify). Note that I'm not trying to suggest actual solutions here, -> but just various directions we can pursue: - -Understood. :) - -> a. A single-assignment VM, which we've both already been thinking -> about. - -Yup, I think that this makes a lot of sense. I am still intrigued, -however, by the prospect of a minimally allocated VM representation... I -think that it could have definate advantages for certain applications -(think very small machines, like PDAs). I don't, however, think that our -initial implementations should focus on this. :) - -Here are some other auxilliary goals that I think we should consider: - -1. Primary goal: Support a high performance dynamic compilation - system. This means that we have an "ideal" division of labor between - the runtime and static compilers. Of course, the other goals of the - system somewhat reduce the importance of this point (f.e. portability - reduces performance, but hopefully not much) -2. Portability to different processors. Since we are most familiar with - x86 and solaris, I think that these two are excellent candidates when - we get that far... -3. Support for all languages & styles of programming (general purpose - VM). This is the point that disallows java style bytecodes, where all - array refs are checked for bounds, etc... -4. Support linking between different language families. For example, call - C functions directly from Java without using the nasty/slow/gross JNI - layer. This involves several subpoints: - A. Support for languages that require garbage collectors and integration - with languages that don't. As a base point, we could insist on - always using a conservative GC, but implement free as a noop, f.e. - -> b. A strongly-typed VM. One question is do we need the types to be -> explicitly declared or should they be inferred by the dynamic -> compiler? - - B. This is kind of similar to another idea that I have: make OOP - constructs (virtual function tables, class heirarchies, etc) explicit - in the VM representation. I believe that the number of additional - constructs would be fairly low, but would give us lots of important - information... something else that would/could be important is to - have exceptions as first class types so that they would be handled in - a uniform way for the entire VM... so that C functions can call Java - functions for example... - -> c. How do we get more high-level information into the VM while keeping -> to a low-level VM design? -> o Explicit array references as operands? An alternative is -> to have just an array type, and let the index computations be -> separate 3-operand instructions. - - C. In the model I was thinking of (subject to change of course), we - would just have an array type (distinct from the pointer - types). This would allow us to have arbitrarily complex index - expressions, while still distinguishing "load" from "Array load", - for example. Perhaps also, switch jump tables would be first class - types as well? This would allow better reasoning about the program. - -5. Support dynamic loading of code from various sources. Already - mentioned above was the example of loading java bytecodes, but we want - to support dynamic loading of VM code as well. This makes the job of - the runtime compiler much more interesting: it can do interprocedural - optimizations that the static compiler can't do, because it doesn't - have all of the required information (for example, inlining from - shared libraries, etc...) - -6. Define a set of generally useful annotations to add to the VM - representation. For example, a function can be analysed to see if it - has any sideeffects when run... also, the MOD/REF sets could be - calculated, etc... we would have to determine what is reasonable. This - would generally be used to make IP optimizations cheaper for the - runtime compiler... - -> o Explicit instructions to handle aliasing, e.g.s: -> -- an instruction to say "I speculate that these two values are not -> aliased, but check at runtime", like speculative execution in -> EPIC? -> -- or an instruction to check whether two values are aliased and -> execute different code depending on the answer, somewhat like -> predicated code in EPIC - -These are also very good points... if this can be determined at compile -time. I think that an epic style of representation (not the instruction -packing, just the information presented) could be a very interesting model -to use... more later... - -> o (This one is a difficult but powerful idea.) -> A "thread-id" field on every instruction that allows the static -> compiler to generate a set of parallel threads, and then have -> the runtime compiler and hardware do what they please with it. -> This has very powerful uses, but thread-id on every instruction -> is expensive in terms of instruction size and code size. -> We would need to compactly encode it somehow. - -Yes yes yes! :) I think it would be *VERY* useful to include this kind -of information (which EPIC architectures *implicitly* encode. The trend -that we are seeing supports this greatly: - -1. Commodity processors are getting massive SIMD support: - * Intel/Amd MMX/MMX2 - * AMD's 3Dnow! - * Intel's SSE/SSE2 - * Sun's VIS -2. SMP is becoming much more common, especially in the server space. -3. Multiple processors on a die are right around the corner. - -If nothing else, not designing this in would severely limit our future -expansion of the project... - -> Also, this will require some reading on at least two other -> projects: -> -- Multiscalar architecture from Wisconsin -> -- Simultaneous multithreading architecture from Washington -> -> o Or forget all this and stick to a traditional instruction set? - -Heh... :) Well, from a pure research point of view, it is almost more -attactive to go with the most extreme/different ISA possible. On one axis -you get safety and conservatism, and on the other you get degree of -influence that the results have. Of course the problem with pure research -is that often times there is no concrete product of the research... :) - -> BTW, on an unrelated note, after the meeting yesterday, I did remember -> that you had suggested doing instruction scheduling on SSA form instead -> of a dependence DAG earlier in the semester. When we talked about -> it yesterday, I didn't remember where the idea had come from but I -> remembered later. Just giving credit where its due... - -:) Thanks. - -> Perhaps you can save the above as a file under RCS so you and I can -> continue to expand on this. - -I think it makes sense to do so when we get our ideas more formalized and -bounce it back and forth a couple of times... then I'll do a more formal -writeup of our goals and ideas. Obviously our first implementation will -not want to do all of the stuff that I pointed out above... be we will -want to design the project so that we do not artificially limit ourselves -at sometime in the future... - -Anyways, let me know what you think about these ideas... and if they sound -reasonable... - --Chris - -- cgit v1.2.3