40 lines · plain
1Date: Tue, 13 Feb 2001 13:29:52 -0600 (CST)2From: Chris Lattner <sabre@nondot.org>3To: Vikram S. Adve <vadve@cs.uiuc.edu>4Subject: LLVM Concerns...5 6 7I've updated the documentation to include load store and allocation8instructions (please take a look and let me know if I'm on the right9track):10 11file:/home/vadve/lattner/llvm/docs/LangRef.html#memoryops12 13I have a couple of concerns I would like to bring up:14 151. Reference types16 Right now, I've spec'd out the language to have a pointer type, which17 works fine for lots of stuff... except that Java really has18 references: constrained pointers that cannot be manipulated: added and19 subtracted, moved, etc... Do we want to have a type like this? It20 could be very nice for analysis (pointer always points to the start of21 an object, etc...) and more closely matches Java semantics. The22 pointer type would be kept for C++ like semantics. Through analysis,23 C++ pointers could be promoted to references in the LLVM24 representation.25 262. 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 are29 independent and can share the same memory source object, there is30 no way to represent this in either the bytecode or assembly.31 B. When parsing assembly/bytecode, we effectively have to do a full32 SSA generation/PHI node insertion pass to build the dependencies33 when we don't want the "pinned" representation. This is not34 cool.35 I'm tempted to make memory references explicit in both the assembly and36 bytecode to get around this... what do you think?37 38-Chris39 40