add some more notes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81170 91177308-0d34-0410-b5e6-96231b3b80d8

docs/LangRef.html

@@ -2118,7 +2118,46 @@ logically read from arbitrary registers that happen to be around when needed,
 so the value is not neccesarily consistent over time.  In fact, %A and %C need
 to have the same semantics of the core LLVM "replace all uses with" concept
 would not hold.</p>
-  
+
+<div class="doc_code">
+<pre>
+  %A = fdiv undef, %X
+  %B = fdiv %X, undef
+Safe:
+  %A = undef
+b: unreachable
+</pre>
+</div>
+
+<p>These examples show the crucial difference between an <em>undefined
+value</em> and <em>undefined behavior</em>.  An undefined value (like undef) is
+allowed to have an arbitrary bit-pattern.  This means that the %A operation
+can be constant folded to undef because the undef could be an SNaN, and fdiv is
+not (currently) defined on SNaN's.  However, in the second example, we can make
+a more aggressive assumption: because the undef is allowed to be an arbitrary
+value, we are allowed to assume that it could be zero.  Since a divide by zero
+is has <em>undefined behavior</em>, we are allowed to assume that the operation
+does not execute at all.  This allows us to delete the divide and all code after
+it: since the undefined operation "can't happen", the optimizer can assume that
+it occurs in dead code.
+</p>
+ 
+<div class="doc_code">
+<pre>
+a:  store undef -> %X
+b:  store %X -> undef
+Safe:
+a: &lt;deleted&gt;
+b: unreachable
+</pre>
+</div>
+
+<p>These examples reiterate the fdiv example: a store "of" an undefined value
+can be assumed to not have any effect: we can assume that the value is 
+overwritten with bits that happen to match what was already there.  However, a
+store "to" an undefined location could clobber arbitrary memory, therefore, it
+has undefined behavior.</p>
+
 </div>
 
 <!-- ======================================================================= -->