docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt

   1 Date: Tue, 13 Feb 2001 18:25:42 -0600
   2 From: Vikram S. Adve <vadve@cs.uiuc.edu>
   3 To: Chris Lattner <sabre@nondot.org>
   4 Subject: RE: LLVM Concerns...
   5
   6 > 1. Reference types
   7 >    Right now, I've spec'd out the language to have a pointer type, which
   8 >    works fine for lots of stuff... except that Java really has
   9 >    references: constrained pointers that cannot be manipulated: added and
  10 >    subtracted, moved, etc... Do we want to have a type like this?  It
  11 >    could be very nice for analysis (pointer always points to the start of
  12 >    an object, etc...) and more closely matches Java semantics.  The
  13 >    pointer type would be kept for C++ like semantics.  Through analysis,
  14 >    C++ pointers could be promoted to references in the LLVM
  15 >    representation.
  16
  17
  18 You're right, having references would be useful.  Even for C++ the *static*
  19 compiler could generate references instead of pointers with fairly
  20 straightforward analysis.  Let's include a reference type for now.  But I'm
  21 also really concerned that LLVM is becoming big and complex and (perhaps)
  22 too high-level.  After we get some initial performance results, we may have
  23 a clearer idea of what our goals should be and we should revisit this
  24 question then.
  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,
  30
  31 not sure what you meant by "share the same memory source object"
  32
  33 > there is
  34 >          no way to represent this in either the bytecode or assembly.
  35 >       B. When parsing assembly/bytecode, we effectively have to do a full
  36 >          SSA generation/PHI node insertion pass to build the dependencies
  37 >          when we don't want the "pinned" representation.  This is not
  38 >          cool.
  39
  40 I understand the concern.  But again, let's focus on the performance first
  41 and then look at the language design issues.  E.g., it would be good to know
  42 how big the bytecode files are before expanding them further.  I am pretty
  43 keen to explore the implications of LLVM for mobile devices.  Both bytecode
  44 size and power consumption are important to consider there.
  45
  46 --Vikram
  47