|
150
|
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
|
