diff options
author | mike-m <mikem.llvm@gmail.com> | 2010-05-07 00:28:04 +0000 |
---|---|---|
committer | mike-m <mikem.llvm@gmail.com> | 2010-05-07 00:28:04 +0000 |
commit | e2c3a49c8029ebd9ef530101cc24c66562e3dff5 (patch) | |
tree | 91bf9600cc8df90cf99751a8f8bafc317cffc91e /docs/HistoricalNotes/2001-02-13-Reference-Memory.txt | |
parent | c10b5afbe8138b0fdf3af4ed3e1ddf96cf3cb4cb (diff) | |
download | llvm-e2c3a49c8029ebd9ef530101cc24c66562e3dff5.tar.gz llvm-e2c3a49c8029ebd9ef530101cc24c66562e3dff5.tar.bz2 llvm-e2c3a49c8029ebd9ef530101cc24c66562e3dff5.tar.xz |
Revert r103213. It broke several sections of live website.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103219 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs/HistoricalNotes/2001-02-13-Reference-Memory.txt')
-rw-r--r-- | docs/HistoricalNotes/2001-02-13-Reference-Memory.txt | 39 |
1 files changed, 39 insertions, 0 deletions
diff --git a/docs/HistoricalNotes/2001-02-13-Reference-Memory.txt b/docs/HistoricalNotes/2001-02-13-Reference-Memory.txt new file mode 100644 index 0000000000..2c7534d9da --- /dev/null +++ b/docs/HistoricalNotes/2001-02-13-Reference-Memory.txt @@ -0,0 +1,39 @@ +Date: Tue, 13 Feb 2001 13:29:52 -0600 (CST) +From: Chris Lattner <sabre@nondot.org> +To: Vikram S. Adve <vadve@cs.uiuc.edu> +Subject: LLVM Concerns... + + +I've updated the documentation to include load store and allocation +instructions (please take a look and let me know if I'm on the right +track): + +file:/home/vadve/lattner/llvm/docs/LangRef.html#memoryops + +I have a couple of concerns I would like to bring up: + +1. Reference types + Right now, I've spec'd out the language to have a pointer type, which + works fine for lots of stuff... except that Java really has + references: constrained pointers that cannot be manipulated: added and + subtracted, moved, etc... Do we want to have a type like this? It + could be very nice for analysis (pointer always points to the start of + an object, etc...) and more closely matches Java semantics. The + pointer type would be kept for C++ like semantics. Through analysis, + C++ pointers could be promoted to references in the LLVM + representation. + +2. Our "implicit" memory references in assembly language: + After thinking about it, this model has two problems: + A. If you do pointer analysis and realize that two stores are + independent and can share the same memory source object, there is + no way to represent this in either the bytecode or assembly. + B. When parsing assembly/bytecode, we effectively have to do a full + SSA generation/PHI node insertion pass to build the dependencies + when we don't want the "pinned" representation. This is not + cool. + I'm tempted to make memory references explicit in both the assembly and + bytecode to get around this... what do you think? + +-Chris + |