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 --- .../2001-02-13-Reference-MemoryResponse.txt | 47 ---------------------- 1 file changed, 47 deletions(-) delete mode 100644 docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt (limited to 'docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt') diff --git a/docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt b/docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt deleted file mode 100644 index 505343378d..0000000000 --- a/docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt +++ /dev/null @@ -1,47 +0,0 @@ -Date: Tue, 13 Feb 2001 18:25:42 -0600 -From: Vikram S. Adve -To: Chris Lattner -Subject: RE: LLVM Concerns... - -> 1. Reference types -> Right now, I've spec'd out the language to have a pointer type, which -> works fine for lots of stuff... except that Java really has -> references: constrained pointers that cannot be manipulated: added and -> subtracted, moved, etc... Do we want to have a type like this? It -> could be very nice for analysis (pointer always points to the start of -> an object, etc...) and more closely matches Java semantics. The -> pointer type would be kept for C++ like semantics. Through analysis, -> C++ pointers could be promoted to references in the LLVM -> representation. - - -You're right, having references would be useful. Even for C++ the *static* -compiler could generate references instead of pointers with fairly -straightforward analysis. Let's include a reference type for now. But I'm -also really concerned that LLVM is becoming big and complex and (perhaps) -too high-level. After we get some initial performance results, we may have -a clearer idea of what our goals should be and we should revisit this -question then. - -> 2. Our "implicit" memory references in assembly language: -> After thinking about it, this model has two problems: -> A. If you do pointer analysis and realize that two stores are -> independent and can share the same memory source object, - -not sure what you meant by "share the same memory source object" - -> there is -> no way to represent this in either the bytecode or assembly. -> B. When parsing assembly/bytecode, we effectively have to do a full -> SSA generation/PHI node insertion pass to build the dependencies -> when we don't want the "pinned" representation. This is not -> cool. - -I understand the concern. But again, let's focus on the performance first -and then look at the language design issues. E.g., it would be good to know -how big the bytecode files are before expanding them further. I am pretty -keen to explore the implications of LLVM for mobile devices. Both bytecode -size and power consumption are important to consider there. - ---Vikram - -- cgit v1.2.3