<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/flang/docs/ArrayRepacking.md, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[flang] Defined SafeTempArrayCopyAttrInterface for array repacking. (#134346)</title>
<updated>2025-04-11T01:41:54+00:00</updated>
<author>
<name>Slava Zakharin</name>
<email>szakharin@nvidia.com</email>
</author>
<published>2025-04-11T01:41:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9aff19e7a3ff22ad15dc52609c65c785d4621fca'/>
<id>9aff19e7a3ff22ad15dc52609c65c785d4621fca</id>
<content type='text'>
This patch defines `fir::SafeTempArrayCopyAttrInterface` and the
corresponding
OpenACC/OpenMP related attributes in FIR dialect. The actual
implementations
are just placeholders right now, and array repacking becomes a no-op
if `-fopenacc/-fopenmp` is used for the compilation.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch defines `fir::SafeTempArrayCopyAttrInterface` and the
corresponding
OpenACC/OpenMP related attributes in FIR dialect. The actual
implementations
are just placeholders right now, and array repacking becomes a no-op
if `-fopenacc/-fopenmp` is used for the compilation.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] Added driver options for arrays repacking. (#134002)</title>
<updated>2025-04-03T17:43:28+00:00</updated>
<author>
<name>Slava Zakharin</name>
<email>szakharin@nvidia.com</email>
</author>
<published>2025-04-03T17:43:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3f6ae3f0a81ac32aee7633b7c240ce8eb25192ff'/>
<id>3f6ae3f0a81ac32aee7633b7c240ce8eb25192ff</id>
<content type='text'>
Added options:
  * -f[no-]repack-arrays
  * -f[no-]stack-repack-arrays
  * -frepack-arrays-contiguity=whole/innermost</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Added options:
  * -f[no-]repack-arrays
  * -f[no-]stack-repack-arrays
  * -frepack-arrays-contiguity=whole/innermost</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] Recognize fir.pack_array in LoopVersioning. (#133191)</title>
<updated>2025-03-31T18:41:43+00:00</updated>
<author>
<name>Slava Zakharin</name>
<email>szakharin@nvidia.com</email>
</author>
<published>2025-03-31T18:41:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0ac8cb1b3df724f549a62f6b277745af3d50b23a'/>
<id>0ac8cb1b3df724f549a62f6b277745af3d50b23a</id>
<content type='text'>
This change enables LoopVersioning when `fir.pack_array` is met
in the def-use chain. It fixes a couple of huge performance regressions
caused by enabling `-frepack-arrays`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This change enables LoopVersioning when `fir.pack_array` is met
in the def-use chain. It fixes a couple of huge performance regressions
caused by enabling `-frepack-arrays`.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang] Fixed repacking for TARGET and INTENT(OUT) (#131972)</title>
<updated>2025-03-20T00:12:32+00:00</updated>
<author>
<name>Slava Zakharin</name>
<email>szakharin@nvidia.com</email>
</author>
<published>2025-03-20T00:12:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2c91f10362502ebfb464691cdde1ba05be7cb50e'/>
<id>2c91f10362502ebfb464691cdde1ba05be7cb50e</id>
<content type='text'>
TARGET dummy arrays can be accessed indirectly, so it is unsafe
to repack them.
INTENT(OUT) dummy arrays that require finalization on entry
to their subroutine must be copied-in by `fir.pack_arrays`.

In addition, based on my testing results, I think it will be useful
to document that `LOC` and `IS_CONTIGUOUS` will have different values
for the repacked arrays. I still need to decide where to document
this, so just added a note in the design doc for the time being.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
TARGET dummy arrays can be accessed indirectly, so it is unsafe
to repack them.
INTENT(OUT) dummy arrays that require finalization on entry
to their subroutine must be copied-in by `fir.pack_arrays`.

In addition, based on my testing results, I think it will be useful
to document that `LOC` and `IS_CONTIGUOUS` will have different values
for the repacked arrays. I still need to decide where to document
this, so just added a note in the design doc for the time being.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang-rt] Added ShallowCopy API. (#131702)</title>
<updated>2025-03-18T19:58:25+00:00</updated>
<author>
<name>Slava Zakharin</name>
<email>szakharin@nvidia.com</email>
</author>
<published>2025-03-18T19:58:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7d7b58bc5d2bacc3d76463d2ee06a13d2a08b084'/>
<id>7d7b58bc5d2bacc3d76463d2ee06a13d2a08b084</id>
<content type='text'>
This API will be used for copying non-contiguous arrays
into contiguous temporaries to support `-frepack-arrays`.
The builder factory API will be used in the following commits.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This API will be used for copying non-contiguous arrays
into contiguous temporaries to support `-frepack-arrays`.
The builder factory API will be used in the following commits.</pre>
</div>
</content>
</entry>
<entry>
<title>[RFC][flang] Add support for assumed-shape dummy arrays repacking. (#127147)</title>
<updated>2025-03-10T18:08:37+00:00</updated>
<author>
<name>Slava Zakharin</name>
<email>szakharin@nvidia.com</email>
</author>
<published>2025-03-10T18:08:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=aa3875411746de0a24a8de0d40def711cd70153d'/>
<id>aa3875411746de0a24a8de0d40def711cd70153d</id>
<content type='text'>
This is a document describing why and how to add support for repacking
of assumed-shape dummy arrrays to provide more efficient data cache.
It proposes adding new FIR operations and outlines the compiler flow
handling these operations.
I would like to hear feedback on all of it, but especially on:
  * The possibility of detecting safeness of the repacking
    in the context of OpenACC/OpenMP. If it is not possible
    to do the runtime checks to determine safety, then
    there is not need to add the `TempCopyIsSafe` attributes
    to the instruction.
  * Whether it is possible to preserve the debug information
    in cases where `fir.pack_array` is sunk after `[hl]fir.declare`,
    so that before the `fir.pack_array` a debugger will refer
    to the values in the original array, and after `fir.pack_array`
    it will refer to the copy.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a document describing why and how to add support for repacking
of assumed-shape dummy arrrays to provide more efficient data cache.
It proposes adding new FIR operations and outlines the compiler flow
handling these operations.
I would like to hear feedback on all of it, but especially on:
  * The possibility of detecting safeness of the repacking
    in the context of OpenACC/OpenMP. If it is not possible
    to do the runtime checks to determine safety, then
    there is not need to add the `TempCopyIsSafe` attributes
    to the instruction.
  * Whether it is possible to preserve the debug information
    in cases where `fir.pack_array` is sunk after `[hl]fir.declare`,
    so that before the `fir.pack_array` a debugger will refer
    to the values in the original array, and after `fir.pack_array`
    it will refer to the copy.</pre>
</div>
</content>
</entry>
</feed>
