Dan Gohman | f17a25c | 2007-07-18 16:29:46 +0000 | [diff] [blame] | 1 | Date: Tue, 13 Feb 2001 13:29:52 -0600 (CST) |
| 2 | From: Chris Lattner <sabre@nondot.org> |
| 3 | To: Vikram S. Adve <vadve@cs.uiuc.edu> |
| 4 | Subject: LLVM Concerns... |
| 5 | |
| 6 | |
| 7 | I've updated the documentation to include load store and allocation |
| 8 | instructions (please take a look and let me know if I'm on the right |
| 9 | track): |
| 10 | |
| 11 | file:/home/vadve/lattner/llvm/docs/LangRef.html#memoryops |
| 12 | |
| 13 | I have a couple of concerns I would like to bring up: |
| 14 | |
| 15 | 1. Reference types |
| 16 | Right now, I've spec'd out the language to have a pointer type, which |
| 17 | works fine for lots of stuff... except that Java really has |
| 18 | references: constrained pointers that cannot be manipulated: added and |
| 19 | subtracted, moved, etc... Do we want to have a type like this? It |
| 20 | could be very nice for analysis (pointer always points to the start of |
| 21 | an object, etc...) and more closely matches Java semantics. The |
| 22 | pointer type would be kept for C++ like semantics. Through analysis, |
| 23 | C++ pointers could be promoted to references in the LLVM |
| 24 | representation. |
| 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, there is |
| 30 | no way to represent this in either the bytecode or assembly. |
| 31 | B. When parsing assembly/bytecode, we effectively have to do a full |
| 32 | SSA generation/PHI node insertion pass to build the dependencies |
| 33 | when we don't want the "pinned" representation. This is not |
| 34 | cool. |
| 35 | I'm tempted to make memory references explicit in both the assembly and |
| 36 | bytecode to get around this... what do you think? |
| 37 | |
| 38 | -Chris |
| 39 | |