← Back to branch summary

~pali/+junk/llvm-toolchain-3.7

« back to all changes in this revision

Viewing changes to docs/HistoricalNotes/2001-02-13-Reference-Memory.txt

  • Committer: Package Import Robot
  • Author(s): Sylvestre Ledru
  • Date: 2015-07-15 17:51:08 UTC
  • Revision ID: package-import@ubuntu.com-20150715175108-l8mynwovkx4zx697
Tags: upstream-3.7~+rc2
Import upstream version 3.7~+rc2

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/HistoricalNotes/2001-02-13-Reference-Memory.txt
 
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