Mercurial > hg > CbC > CbC_llvm
comparison docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt @ 0:95c75e76d11b LLVM3.4
LLVM 3.4
| author | Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Thu, 12 Dec 2013 13:56:28 +0900 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| -1:000000000000 | 0:95c75e76d11b |
|---|---|
| 1 Date: Tue, 13 Feb 2001 18:25:42 -0600 | |
| 2 From: Vikram S. Adve <vadve@cs.uiuc.edu> | |
| 3 To: Chris Lattner <sabre@nondot.org> | |
| 4 Subject: RE: LLVM Concerns... | |
| 5 | |
| 6 > 1. Reference types | |
| 7 > Right now, I've spec'd out the language to have a pointer type, which | |
| 8 > works fine for lots of stuff... except that Java really has | |
| 9 > references: constrained pointers that cannot be manipulated: added and | |
| 10 > subtracted, moved, etc... Do we want to have a type like this? It | |
| 11 > could be very nice for analysis (pointer always points to the start of | |
| 12 > an object, etc...) and more closely matches Java semantics. The | |
| 13 > pointer type would be kept for C++ like semantics. Through analysis, | |
| 14 > C++ pointers could be promoted to references in the LLVM | |
| 15 > representation. | |
| 16 | |
| 17 | |
| 18 You're right, having references would be useful. Even for C++ the *static* | |
| 19 compiler could generate references instead of pointers with fairly | |
| 20 straightforward analysis. Let's include a reference type for now. But I'm | |
| 21 also really concerned that LLVM is becoming big and complex and (perhaps) | |
| 22 too high-level. After we get some initial performance results, we may have | |
| 23 a clearer idea of what our goals should be and we should revisit this | |
| 24 question then. | |
| 25 | |
| 26 > 2. Our "implicit" memory references in assembly language: | |
| 27 > After thinking about it, this model has two problems: | |
| 28 > A. If you do pointer analysis and realize that two stores are | |
| 29 > independent and can share the same memory source object, | |
| 30 | |
| 31 not sure what you meant by "share the same memory source object" | |
| 32 | |
| 33 > there is | |
| 34 > no way to represent this in either the bytecode or assembly. | |
| 35 > B. When parsing assembly/bytecode, we effectively have to do a full | |
| 36 > SSA generation/PHI node insertion pass to build the dependencies | |
| 37 > when we don't want the "pinned" representation. This is not | |
| 38 > cool. | |
| 39 | |
| 40 I understand the concern. But again, let's focus on the performance first | |
| 41 and then look at the language design issues. E.g., it would be good to know | |
| 42 how big the bytecode files are before expanding them further. I am pretty | |
| 43 keen to explore the implications of LLVM for mobile devices. Both bytecode | |
| 44 size and power consumption are important to consider there. | |
| 45 | |
| 46 --Vikram | |
| 47 |