2009-05-26 Basile Starynkevitch <basile@starynkevitch.net>

	MELT branch merged with trunk r147859



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/melt-branch@147861 138bc75d-0d04-0410-961f-82ee72b054a4

1 files changed, 32 insertions, 3 deletions

diff --git a/gcc/doc/tree-ssa.texi b/gcc/doc/tree-ssa.texi
index 659431b0274..ebb85a05769 100644
--- a/gcc/doc/tree-ssa.texi
+++ b/gcc/doc/tree-ssa.texi
@@ -41,6 +41,7 @@ passes for GIMPLE@.
 * SSA Operands::  	SSA names referenced by GIMPLE statements.
 * SSA::                 Static Single Assignment representation.
 * Alias analysis::      Representing aliased loads and stores.
+* Memory model::        Memory model used by the middle-end.
 @end menu
 
 @node Annotations
@@ -108,9 +109,9 @@ full object that they represent.  For instance, given
 
 Since @code{a} and @code{b} are non-aliased locals, the statement
 @code{a = b} will have one real definition and one real use because
-variable @code{b} is completely modified with the contents of
-variable @code{a}.  Real definition are also known as @dfn{killing
-definitions}.  Similarly, the use of @code{a} reads all its bits.
+variable @code{a} is completely modified with the contents of
+variable @code{b}.  Real definition are also known as @dfn{killing
+definitions}.  Similarly, the use of @code{b} reads all its bits.
 
 In contrast, virtual operands are used with variables that can have
 a partial or ambiguous reference.  This includes structures, arrays,
@@ -892,3 +893,31 @@ providing its aliasing VDEF.  The walk stops if asked to.
 
 @end enumerate
 
+
+@node Memory model
+@section Memory model
+@cindex memory model
+
+The memory model used by the middle-end models that of the C/C++
+languages.  The middle-end has the notion of an effective type
+of a memory region which is used for type-based alias analysis.
+
+The following is a refinement of ISO C99 6.5/6, clarifying the block copy case
+to follow common sense and extending the concept of a dynamic effective
+type to objects with a declared type as required for C++.
+
+@smallexample
+The effective type of an object for an access to its stored value is
+the declared type of the object or the effective type determined by
+a previous store to it.  If a value is stored into an object through
+an lvalue having a type that is not a character type, then the
+type of the lvalue becomes the effective type of the object for that
+access and for subsequent accesses that do not modify the stored value.
+If a value is copied into an object using @code{memcpy} or @code{memmove},
+or is copied as an array of character type, then the effective type
+of the modified object for that access and for subsequent accesses that
+do not modify the value is undetermined.  For all other accesses to an
+object, the effective type of the object is simply the type of the
+lvalue used for the access.
+@end smallexample
+