[Docs] Fix a statement wrt instruction alignment of 0

[xgupta]

Summary

This fix https://github.com/llvm/llvm-project/issues/53371
Zero is not a legal alignment.

[nikic]

LGTM

[xgupta]

sorry, I missed and committed, you have also added a new reviewer.

[efriedma]

It looks like the definition of stores has the same "value of 0 or" language?

Otherwise looks fine.

[xgupta]

In D142633#4086574, @efriedma wrote:

It looks like the definition of stores has the same "value of 0 or" language?

Otherwise looks fine.

Fix in https://reviews.llvm.org/rG6cfebf39103e6f46dfb3ed50930b81cb674384e5.

llvm/docs/LangRef.rst

 multiple atomic stores. The type of the pointee must be an integer, pointer, or
 floating-point type whose bit width is a power of two greater than or equal to
 eight and less than or equal to a target-specific size limit.  ``align`` must be
 explicitly specified on atomic stores, and the store has undefined behavior if
 the alignment is not set to a value which is at least the size in bytes of the
 pointee. ``!nontemporal`` does not have any defined semantics for atomic stores.
 
 The optional constant ``align`` argument specifies the alignment of the
-operation (that is, the alignment of the memory address). A value of 0
-or an omitted ``align`` argument means that the operation has the ABI
-alignment for the target. It is the responsibility of the code emitter
-to ensure that the alignment information is correct. Overestimating the
-alignment results in undefined behavior. Underestimating the
-alignment may produce less efficient code. An alignment of 1 is always
-safe. The maximum possible alignment is ``1 << 32``. An alignment
-value higher than the size of the stored type implies memory up to the
-alignment value bytes can be stored to without trapping in the default
-address space. Storing to the higher bytes however may result in data
-races if another thread can access the same address. Introducing a
+operation (that is, the alignment of the memory address). An omitted ``align``
+argument means that the operation has the ABI alignment for the target.
+It is the responsibility of the code emitter to ensure that the alignment
+information is correct. Overestimating the alignment results in undefined
+behavior. Underestimating the alignment may produce less efficient code.
+An alignment of 1 is always safe. The maximum possible alignment is ``1 << 32``.
+An alignment value higher than the size of the stored type implies memory
+up to the alignment value bytes can be stored to without trapping in
+the default address space. Storing to the higher bytes however may result in
+data races if another thread can access the same address. Introducing a
 data race is not allowed. Storing to the extra bytes is not allowed
 even in situations where a data race is known to not exist if the
 function has the ``sanitize_address`` attribute.
 
 The optional ``!nontemporal`` metadata must reference a single metadata
 name ``<nontemp_node>`` corresponding to a metadata node with one ``i32`` entry
 of value 1. The existence of the ``!nontemporal`` metadata on the instruction
 tells the optimizer and code generator that this load is not expected to