f16 FDIV can now be legalized by promoting to f32

[oota-llvm.git] / docs / Atomics.html

diff --git a/docs/Atomics.html b/docs/Atomics.html
index d4a3795b9dfecb7ce6eb21a1f4eb2e3adc71203a..fc15e27c39cd765233d8e7d40447e86a8b0eab33 100644 (file)
--- a/docs/Atomics.html
+++ b/docs/Atomics.html
@@ -308,7 +308,7 @@ void f(int* a) {
       which would make those optimizations useful.</dd>
   <dt>Notes for code generation</dt>
   <dd>Code generation is essentially the same as that for unordered for loads
-     and stores.  No fences is required.  <code>cmpxchg</code> and 
+     and stores.  No fences are required.  <code>cmpxchg</code> and 
      <code>atomicrmw</code> are required to appear as a single operation.</dd>
 </dl>
 
@@ -437,10 +437,10 @@ void f(int* a) {
       SequentiallyConsistent operations may not be reordered.</dd>
   <dt>Notes for code generation</dt>
   <dd>SequentiallyConsistent loads minimally require the same barriers
-     as Acquire operations and SequeuentiallyConsistent stores require
+     as Acquire operations and SequentiallyConsistent stores require
      Release barriers. Additionally, the code generator must enforce
-     ordering between SequeuentiallyConsistent stores followed by
-     SequeuentiallyConsistent loads. This is usually done by emitting
+     ordering between SequentiallyConsistent stores followed by
+     SequentiallyConsistent loads. This is usually done by emitting
      either a full fence before the loads or a full fence after the
      stores; which is preferred varies by architecture.</dd>
 </dl>