Imported Upstream version 5.18.0.167

Former-commit-id: 289509151e0fee68a1b591a20c9f109c3c789d3a

external/llvm/docs/HistoricalNotes/2001-02-13-Reference-Memory.txt

@@ -1,39 +0,0 @@
-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
-