[AMDGPU, docs] Fix typos

[Flakebi]

Looks good, thanks!

Maybe give the commit a more meaningful title than ‘test commit access’ :)

[t-tye]

llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst

115

I am not sure that it is possible with current DWARF to express information for *any* optimized AMD GPU code. So I think the original statement is accurate. This is not about improving, it is about getting to even work in the first place.

[RamNalamothu]

llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst

115

Got it. Thank you.

[RamNalamothu]

Update the title and address review comments.

[RamNalamothu]

Another attempt to update title. New to arcanist :)

[t-tye]

LGTM

llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst

 characteristics and requirements as AMDGPU devices. Some of the extension can
 also apply to traditional CPU hardware that supports large vector registers.
 Compilers can map source languages and extensions that describe large scale
 parallel execution onto the lanes of the vector registers. This is common in
 programming languages used in ML and HPC. The extensions also include improved
 support for optimized code on any architecture. Some of the generalizations may
 also benefit other issues that have been raised.
 
-The extensions have evolved though collaboration with many individuals and
+The extensions have evolved through collaboration with many individuals and
 active prototyping within the GDB debugger and LLVM compiler. Input has also
 been very much appreciated from the developers working on the Perforce TotalView
 HPC Debugger and GCC compiler.
 
 The AMDGPU has several features that require additional DWARF functionality in
-order to support optimized code.
+order to achieve better debugging experience for the optimized code.
 
 AMDGPU optimized code may spill vector registers to non-global address space
 memory, and this spilling may be done only for lanes that are active on entry
 to the subprogram. To support this, a location description that can be created
 as a masked select is required. See ``DW_OP_LLVM_select_bit_piece``.
 
 Since the active lane mask may be held in a register, a way to get the value
 of a register on entry to a subprogram is required. To support this an

 The vector registers of the AMDGPU are represented as their full wavefront
 size, meaning the wavefront size times the dword size. This reflects the
 actual hardware and allows the compiler to generate DWARF for languages that
 map a thread to the complete wavefront. It also allows more efficient DWARF to
 be generated to describe the CFI as only a single expression is required for
 the whole vector register, rather than a separate expression for each lane's
 dword of the vector register. It also allows the compiler to produce DWARF
 that indexes the vector register if it spills scalar registers into portions
-of a vector registers.
+of a vector register.
 
 Since DWARF stack value entries have a base type and AMDGPU registers are a
 vector of dwords, the ability to specify that a base type is a vector is
 required. See ``DW_AT_LLVM_vector_size``.
 
 If the source language is mapped onto the AMDGPU wavefronts in a SIMT manner,
 then the variable DWARF location expressions must compute the location for a
 single lane of the wavefront. Therefore, a DWARF operation is required to denote