<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/offload/test/offloading/fortran, branch users/nico/python-2</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][OpenMP] Initial defaultmap implementation (#135226)</title>
<updated>2025-05-12T14:30:43+00:00</updated>
<author>
<name>agozillon</name>
<email>Andrew.Gozillon@amd.com</email>
</author>
<published>2025-05-12T14:30:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f687ed9ff717372a7c751a3bf4ef7e33eb481fd6'/>
<id>f687ed9ff717372a7c751a3bf4ef7e33eb481fd6</id>
<content type='text'>
This aims to implement most of the initial arguments for defaultmap
aside from firstprivate and none, and some of the more recent OpenMP 6
additions which will come in subsequent updates (with the OpenMP 6
variants needing parsing/semantic support first).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This aims to implement most of the initial arguments for defaultmap
aside from firstprivate and none, and some of the more recent OpenMP 6
additions which will come in subsequent updates (with the OpenMP 6
variants needing parsing/semantic support first).</pre>
</div>
</content>
</entry>
<entry>
<title>[Flang][OpenMP] Generate correct present checks for implicit maps of optional allocatables (#138210)</title>
<updated>2025-05-09T11:57:45+00:00</updated>
<author>
<name>agozillon</name>
<email>Andrew.Gozillon@amd.com</email>
</author>
<published>2025-05-09T11:57:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b291cfcad4815568dc1eaca58185d25dceed3f1c'/>
<id>b291cfcad4815568dc1eaca58185d25dceed3f1c</id>
<content type='text'>
Currently, we do not generate the appropriate checks to check if an
optional
allocatable argument is present before accessing relevant components of
it,
in particular when creating bounds, we must generate a presence check
and we
must make sure we do not generate/keep an load external to the presence
check
by utilising the raw address rather than the regular address of the info
data structure.

Similarly in cases for optional allocatables we must treat them like
non-allocatable
arguments and generate an intermediate allocation that we can have as a
location
in memory that we can access later in the lowering without causing
segfaults when
we perform "mapping" on it, even if the end result is an empty
allocatable
(basically, we shouldn't explode if someone tries to map a non-present
optional,
similar to C++ when mapping null data).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, we do not generate the appropriate checks to check if an
optional
allocatable argument is present before accessing relevant components of
it,
in particular when creating bounds, we must generate a presence check
and we
must make sure we do not generate/keep an load external to the presence
check
by utilising the raw address rather than the regular address of the info
data structure.

Similarly in cases for optional allocatables we must treat them like
non-allocatable
arguments and generate an intermediate allocation that we can have as a
location
in memory that we can access later in the lowering without causing
segfaults when
we perform "mapping" on it, even if the end result is an empty
allocatable
(basically, we shouldn't explode if someone tries to map a non-present
optional,
similar to C++ when mapping null data).</pre>
</div>
</content>
</entry>
<entry>
<title>[Flang][OpenMP][MLIR] Check for presence of Box type before emitting store in MapInfoFinalization pass (#135477)</title>
<updated>2025-04-14T15:15:56+00:00</updated>
<author>
<name>agozillon</name>
<email>Andrew.Gozillon@amd.com</email>
</author>
<published>2025-04-14T15:15:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b2c9a58b8f28b353b3f0b4ef98fa704c463ba1a4'/>
<id>b2c9a58b8f28b353b3f0b4ef98fa704c463ba1a4</id>
<content type='text'>
Currently we don't check for the presence of descriptor/BoxTypes before
emitting stores which lower to memcpys, the issue with this is that
users can have optional arguments, where they don't provide an input,
making the argument effectively null. This can still be mapped and this
causes issues at the moment as we'll emit a memcpy for function
arguments to store to a local variable for certain edge cases, when we
perform this memcpy on a null input, we cause a segfault at runtime.

The fix to this is to simply create a branch around the store that
checks if the data we're copying from is actually present. If it is, we
proceed with the store, if it isn't we skip it.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently we don't check for the presence of descriptor/BoxTypes before
emitting stores which lower to memcpys, the issue with this is that
users can have optional arguments, where they don't provide an input,
making the argument effectively null. This can still be mapped and this
causes issues at the moment as we'll emit a memcpy for function
arguments to store to a local variable for certain edge cases, when we
perform this memcpy on a null input, we cause a segfault at runtime.

The fix to this is to simply create a branch around the store that
checks if the data we're copying from is actually present. If it is, we
proceed with the store, if it isn't we skip it.</pre>
</div>
</content>
</entry>
<entry>
<title>[MLIR][OpenMP] Add codegen for teams reductions (#133310)</title>
<updated>2025-04-07T16:47:16+00:00</updated>
<author>
<name>Jan Leyonberg</name>
<email>jan_sjodin@yahoo.com</email>
</author>
<published>2025-04-07T16:47:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=fbc8335311b27d73fb685d5ebfb702f7acf134d2'/>
<id>fbc8335311b27d73fb685d5ebfb702f7acf134d2</id>
<content type='text'>
This patch adds the lowering of teams reductions from the omp dialect to
LLVM-IR. Some minor cleanup was done in clang to remove an unused
parameter.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds the lowering of teams reductions from the omp dialect to
LLVM-IR. Some minor cleanup was done in clang to remove an unused
parameter.</pre>
</div>
</content>
</entry>
<entry>
<title>[offload] Remove bad assert in StaticLoopChunker::Distribute (#132705)</title>
<updated>2025-03-28T09:53:00+00:00</updated>
<author>
<name>macurtis-amd</name>
<email>macurtis@amd.com</email>
</author>
<published>2025-03-28T09:53:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=21a8c63cdc36abbf38b4402c9eb34a26598b8476'/>
<id>21a8c63cdc36abbf38b4402c9eb34a26598b8476</id>
<content type='text'>
When building with asserts enabled, this can actually cause strange
miscompilations because an incorrect llvm.assume is generated at the
point of the assertion.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When building with asserts enabled, this can actually cause strange
miscompilations because an incorrect llvm.assume is generated at the
point of the assertion.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Map ByRef if size/alignment exceed that of a pointer (#130832)</title>
<updated>2025-03-13T00:41:11+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2025-03-13T00:41:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f4fc2d731c1b351d5f684f7ec53a0e1ca549df43'/>
<id>f4fc2d731c1b351d5f684f7ec53a0e1ca549df43</id>
<content type='text'>
Improve the check for whether a type can be passed by copy. Currently,
passing by copy is done via the OMP_MAP_LITERAL mapping, which can only
transfer as much data as can be contained in a pointer representation.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Improve the check for whether a type can be passed by copy. Currently,
passing by copy is done via the OMP_MAP_LITERAL mapping, which can only
transfer as much data as can be contained in a pointer representation.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Implement HAS_DEVICE_ADDR clause (#128568)</title>
<updated>2025-03-10T13:11:01+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2025-03-10T13:11:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d67947162f4b06172fac91fefa6a9ad25eb6dd56'/>
<id>d67947162f4b06172fac91fefa6a9ad25eb6dd56</id>
<content type='text'>
The HAS_DEVICE_ADDR indicates that the object(s) listed exists at an
address that is a valid device address. Specifically,
`has_device_addr(x)` means that (in C/C++ terms) `&amp;x` is a device
address.

When entering a target region, `x` does not need to be allocated on the
device, or have its contents copied over (in the absence of additional
mapping clauses). Passing its address verbatim to the region for use is
sufficient, and is the intended goal of the clause.

Some Fortran objects use descriptors in their in-memory representation.
If `x` had a descriptor, both the descriptor and the contents of `x`
would be located in the device memory. However, the descriptors are
managed by the compiler, and can be regenerated at various points as
needed. The address of the effective descriptor may change, hence it's
not safe to pass the address of the descriptor to the target region.
Instead, the descriptor itself is always copied, but for objects like
`x`, no further mapping takes place (as this keeps the storage pointer
in the descriptor unchanged).

---------

Co-authored-by: Sergio Afonso &lt;safonsof@amd.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The HAS_DEVICE_ADDR indicates that the object(s) listed exists at an
address that is a valid device address. Specifically,
`has_device_addr(x)` means that (in C/C++ terms) `&amp;x` is a device
address.

When entering a target region, `x` does not need to be allocated on the
device, or have its contents copied over (in the absence of additional
mapping clauses). Passing its address verbatim to the region for use is
sufficient, and is the intended goal of the clause.

Some Fortran objects use descriptors in their in-memory representation.
If `x` had a descriptor, both the descriptor and the contents of `x`
would be located in the device memory. However, the descriptors are
managed by the compiler, and can be regenerated at various points as
needed. The address of the effective descriptor may change, hence it's
not safe to pass the address of the descriptor to the target region.
Instead, the descriptor itself is always copied, but for objects like
`x`, no further mapping takes place (as this keeps the storage pointer
in the descriptor unchanged).

---------

Co-authored-by: Sergio Afonso &lt;safonsof@amd.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[Flang][OpenMP][MLIR] Implement close, present and ompx_hold modifiers for Flang maps (#129586)</title>
<updated>2025-03-07T21:22:30+00:00</updated>
<author>
<name>agozillon</name>
<email>Andrew.Gozillon@amd.com</email>
</author>
<published>2025-03-07T21:22:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f1178815d2435fdbe9eb5491ff52663e78c8ef7a'/>
<id>f1178815d2435fdbe9eb5491ff52663e78c8ef7a</id>
<content type='text'>
This PR adds an initial implementation for the map modifiers close,
present and ompx_hold, primarily just required adding the appropriate
map type flags to the map type bits. In the case of ompx_hold it
required adding the map type to the OpenMP dialect. Close has a bit of a
problem when utilised with the ALWAYS map type on descriptors, so it is
likely we'll have to make sure close and always are not applied to the
descriptor simultaneously in the future when we apply always to the
descriptors to facilitate movement of descriptor information to device
for consistency, however, we may find an alternative to this with
further investigation. For the moment, it is a TODO/Note to keep track
of it.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This PR adds an initial implementation for the map modifiers close,
present and ompx_hold, primarily just required adding the appropriate
map type flags to the map type bits. In the case of ompx_hold it
required adding the map type to the OpenMP dialect. Close has a bit of a
problem when utilised with the ALWAYS map type on descriptors, so it is
likely we'll have to make sure close and always are not applied to the
descriptor simultaneously in the future when we apply always to the
descriptors to facilitate movement of descriptor information to device
for consistency, however, we may find an alternative to this with
further investigation. For the moment, it is a TODO/Note to keep track
of it.</pre>
</div>
</content>
</entry>
<entry>
<title>[MLIR][OpenMP] Add LLVM translation support for OpenMP UserDefinedMappers (#124746)</title>
<updated>2025-02-18T17:55:48+00:00</updated>
<author>
<name>Akash Banerjee</name>
<email>akash.banerjee@amd.com</email>
</author>
<published>2025-02-18T17:55:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=785a5b4676e7aa77904babb9f66e862b5fc39295'/>
<id>785a5b4676e7aa77904babb9f66e862b5fc39295</id>
<content type='text'>
This patch adds OpenMPToLLVMIRTranslation support for the OpenMP Declare
Mapper directive.

Since both MLIR and Clang now support custom mappers, I've changed the
respective function params to no longer be optional as well.

Depends on #121005</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds OpenMPToLLVMIRTranslation support for the OpenMP Declare
Mapper directive.

Since both MLIR and Clang now support custom mappers, I've changed the
respective function params to no longer be optional as well.

Depends on #121005</pre>
</div>
</content>
</entry>
<entry>
<title>[Offload][NFC] Fix typos discovered by codespell (#125119)</title>
<updated>2025-01-31T15:35:29+00:00</updated>
<author>
<name>Christian Clauss</name>
<email>cclauss@me.com</email>
</author>
<published>2025-01-31T15:35:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1f56bb3137827d66093b66aa3a6447fdaba61783'/>
<id>1f56bb3137827d66093b66aa3a6447fdaba61783</id>
<content type='text'>
https://github.com/codespell-project/codespell

% `codespell
--ignore-words-list=archtype,hsa,identty,inout,iself,nd,te,ths,vertexes
--write-changes`</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
https://github.com/codespell-project/codespell

% `codespell
--ignore-words-list=archtype,hsa,identty,inout,iself,nd,te,ths,vertexes
--write-changes`</pre>
</div>
</content>
</entry>
</feed>
