[LangRef] Fix typos in the vector-type memory layout section

[frasercrmck]

I saw this change in LLVM Weekly and noticed a couple of small issues. I put this up for review rather than pushing it straight through since I haven't touched the LangRef before and may be unaware of something.

[bjope]

LGTM! (Thanks!)

llvm/docs/LangRef.rst

 A bitcast from a vector type to a scalar integer type will see the elements
 being packed together (without padding). The order in which elements are
 inserted in the integer depends on endianess. For little endian element zero
 is put in the least significant bits of the integer, and for big endian
 element zero is put in the most significant bits.
 
 Using a vector such as ``<i4 1, i4 2, i4 3, i4 5>`` as an example, together
 with the analogy that we can replace a vector store by a bitcast followed by
-an integer store, we ge this for big endian:
+an integer store, we get this for big endian:
 
 .. code-block:: llvm
 
       %val = bitcast <4 x i4> <i4 1, i4 2, i4 3, i4 5> to i16
 
       ; Bitcasting from a vector to an integral type can be seen as
       ; concatenating the values:
       ;   %val now has the hexadecimal value 0x1235.
.. code-block:: llvm
       ; In memory the content will be (8-bit addressing):
       ;
       ;    [%ptr + 0]: 01010011  (0x53)
       ;    [%ptr + 1]: 00100001  (0x21)
 
 When ``<N*M>`` isn't evenly divisible by the byte size the exact memory layout
 is unspecified (just like it is for an integral type of the same size). This
 is because different targets could put the padding at different positions when
-the type size is smaller than the types store size.
+the type size is smaller than the type's store size.
 
 :Syntax:
 
 ::
 
       < <# elements> x <elementtype> >          ; Fixed-length vector
       < vscale x <# elements> x <elementtype> > ; Scalable vector