[IR][doc] Alignment is always set in memory for load/store/alloca/cmpxchg/atomicrmw.

[gchatelet]

Summary

Context https://reviews.llvm.org/D142459#4081179

[efriedma]

The phrasing isn't grammatically correct. I would say something like:

"The alignment is only optional when parsing textual IR; for in-memory IR, it is always present."

If you want to try to rearrange the text a bit, maybe put all discussion of the "optional-ness" of the alignment into a separate paragraph from the main definition of alignment.

[gchatelet]

• Address comments

[gchatelet]

In D142625#4083421, @efriedma wrote:

The phrasing isn't grammatically correct. I would say something like:

"The alignment is only optional when parsing textual IR; for in-memory IR, it is always present."

If you want to try to rearrange the text a bit, maybe put all discussion of the "optional-ness" of the alignment into a separate paragraph from the main definition of alignment.

Thx for the suggestion. I've reworded a bit, let me know what you think.

[efriedma]

LGTM, but there's probably a merge conflict with D142633.

[gchatelet]

• Address comments

[gchatelet]

In D142625#4086606, @efriedma wrote:

LGTM, but there's probably a merge conflict with D142633.

Thx for the heads up.
I've updated the patch accordingly but there is still a reference to 0 for alloca. I suppose this should go away as well right?

[efriedma]

I suppose this should go away as well right?

Yes, I think so.

[gchatelet]

• rebase
• remove handling of the 0 value for alloca's alignement

llvm/docs/LangRef.rst

 bytes of memory on the runtime stack, returning a pointer of the
 appropriate type to the program. If "NumElements" is specified, it is
 the number of elements allocated, otherwise "NumElements" is defaulted
 to be one. If a constant alignment is specified, the value result of the
 allocation is guaranteed to be aligned to at least that boundary. The
 alignment may not be greater than ``1 << 32``. If not specified, or if
 zero, the target can choose to align the allocation on any convenient
 boundary compatible with the type.
+Note that if the ``align`` argument is optional in the textual IR format,
+it is always defined in memory.
 
 '``type``' may be any sized type.
 
 Semantics:
 """"""""""
 
 Memory is allocated; a pointer is returned. The allocated memory is
 uninitialized, and loading from uninitialized memory produces an undefined

 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 loaded type implies memory up to the alignment
 value bytes can be safely loaded without trapping in the default
 address space. Access of the high bytes can interfere with debugging
 tools, so should not be accessed if the function has the
 ``sanitize_thread`` or ``sanitize_address`` attributes.
+Note that if the ``align`` argument is optional in the textual IR format,
+it is always defined in memory.
 
 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 be reused in the cache. The code
 generator may select special instructions to save cache bandwidth, such
 as the ``MOVNT`` instruction on x86.

 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.
+Note that if the ``align`` argument is optional in the textual IR format,
+it is always defined in memory.
 
 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
 be reused in the cache. The code generator may select special
 instructions to save cache bandwidth, such as the ``MOVNT`` instruction on
 x86.

 ":ref:`syncscope <syncscope>`" argument.
 
 The instruction can take an optional ``align`` attribute.
 The alignment must be a power of two greater or equal to the size of the
 `<value>` type. If unspecified, the alignment is assumed to be equal to the
 size of the '<value>' type. Note that this default alignment assumption is
 different from the alignment used for the load/store instructions when align
 isn't specified.
+Note that if the ``align`` argument is optional in the textual IR format,
+it is always defined in memory.
 
 The pointer passed into cmpxchg must have alignment greater than or
 equal to the size in memory of the operand.
 
 Semantics:
 """"""""""
 
 The contents of memory at the location specified by the '``<pointer>``' operand

 ``atomicrmw`` with other :ref:`volatile operations <volatile>`.
 
 The instruction can take an optional ``align`` attribute.
 The alignment must be a power of two greater or equal to the size of the
 `<value>` type. If unspecified, the alignment is assumed to be equal to the
 size of the '<value>' type. Note that this default alignment assumption is
 different from the alignment used for the load/store instructions when align
 isn't specified.
+Note that if the ``align`` argument is optional in the textual IR format,
+it is always defined in memory.
 
 A ``atomicrmw`` instruction can also take an optional
 ":ref:`syncscope <syncscope>`" argument.
 
 Semantics:
 """"""""""
 
 The contents of memory at the location specified by the '``<pointer>``'