PNaCl documentation: add SIMD vectors.

native_client_sdk/src/doc/reference/pnacl-undefined-behavior.rst

 ========================
 PNaCl Undefined Behavior
 ========================
 
 .. contents::
    :local:
    :backlinks: none
    :depth: 3
 
 .. _undefined_behavior:
@@ skipping 159 matching lines @@
   could mandate flush-to-zero, and may give an API to enable denormals
   in a future release. The latter is problematic for SIMD and
   vectorization support, where some platforms do not support denormal
   SIMD operations.
 * ``NaN`` values are currently not guaranteed to be canonical; see `bug
   3536 <https://code.google.com/p/nativeclient/issues/detail?id=3536>`_.
 * Passing ``NaN`` to STL functions (the math is defined, but the
   function implementation isn't, e.g. ``std::min`` and ``std::max``), is
   well-defined in the *pexe*.
 
+SIMD Vectors
+^^^^^^^^^^^^
+
+SIMD vector instructions aren't part of the C/C++ standards and as such
+their behavior isn't specified at all in C/C++; it is usually left up to
+the target architecture to specify behavior. Portable Native Client
+instead exposed :ref:`Portable SIMD Vectors <portable_simd_vectors>` and
+offers the same guarantees on these vectors as the guarantees offered by
+the contained elements. Of notable interest amongst these guarantees are
+those of alignment for load/store instructions on vectors: they have the
+same alignment restriction as the contained elements.
+
 Hard to Fix
 ^^^^^^^^^^^
 
 * Null pointer/reference has behavior determined by the NaCl sandbox:
 
   * Raises a segmentation fault in the bottom ``64KiB`` bytes on all
     platforms, and on some sandboxes there are further non-writable
     pages after the initial ``64KiB``.
   * Negative offsets aren't handled consistently on all platforms:
     x86-64 and ARM will wrap around to the stack (because they mask the
@@ skipping 22 matching lines @@
   * PNaCl could offer "portable" JIT capabilities where the code hands
     PNaCl some form of LLVM IR, which PNaCl then JIT-compiles.
 
 * Out-of-scope variable usage: will produce unknown data, mostly
   dependent on stack and memory allocation.
 * Data races: any two operations that conflict (target overlapping
   memory), at least one of which is a store or atomic read-modify-write,
   and at least one of which is not atomic: this will be very dependent
   on processor and execution sequence, see :ref:`Memory Model and
   Atomics <memory_model_and_atomics>`.