| Chris Lattner | 2f7c963 | 2001-06-06 20:29:01 +0000 | [diff] [blame] | 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 | |