<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/flang/examples/FeatureList/FeatureList.cpp, branch users/meinersbur/flang_runtime_split-headers</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] Rework LINEAR clause (#119278)</title>
<updated>2024-12-12T18:19:35+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-12-12T18:19:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=03cbe42627c7a7940b47cc1a2cda0120bc9c6d5e'/>
<id>03cbe42627c7a7940b47cc1a2cda0120bc9c6d5e</id>
<content type='text'>
The OmpLinearClause class was a variant of two classes, one for when the
linear modifier was present, and one for when it was absent. These two
classes did not follow the conventions for parse tree nodes, (i.e.
tuple/wrapper/union formats), which necessitated specialization of the
parse tree visitor.

The new form of OmpLinearClause is the standard tuple with a list of
modifiers and an object list. The specialization of parse tree visitor
for it has been removed.
Parsing and unparsing of the new form bears additional complexity due to
syntactical differences between OpenMP 5.2 and prior versions: in OpenMP
5.2 the argument list is post-modified, while in the prior versions, the
step modifier was a post-modifier while the linear modifier had an
unusual syntax of `modifier(list)`.

With this change the LINEAR clause is no different from any other
clauses in terms of its structure and use of modifiers. Modifier
validation and all other checks work the same as with other clauses.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The OmpLinearClause class was a variant of two classes, one for when the
linear modifier was present, and one for when it was absent. These two
classes did not follow the conventions for parse tree nodes, (i.e.
tuple/wrapper/union formats), which necessitated specialization of the
parse tree visitor.

The new form of OmpLinearClause is the standard tuple with a list of
modifiers and an object list. The specialization of parse tree visitor
for it has been removed.
Parsing and unparsing of the new form bears additional complexity due to
syntactical differences between OpenMP 5.2 and prior versions: in OpenMP
5.2 the argument list is post-modified, while in the prior versions, the
step modifier was a post-modifier while the linear modifier had an
unusual syntax of `modifier(list)`.

With this change the LINEAR clause is no different from any other
clauses in terms of its structure and use of modifiers. Modifier
validation and all other checks work the same as with other clauses.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Use new modifiers in IF/LASTPRIVATE (#118128)</title>
<updated>2024-12-02T22:36:31+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-12-02T22:36:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=33faa8285f3dc5ca10e35770b288770b4bbc2bc1'/>
<id>33faa8285f3dc5ca10e35770b288770b4bbc2bc1</id>
<content type='text'>
The usual changes, added more references to OpenMP specs.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The usual changes, added more references to OpenMP specs.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Use new modifiers in DEPEND/GRAINSIZE/NUM_TASKS (#117917)</title>
<updated>2024-12-02T21:22:05+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-12-02T21:22:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=bde79c0e27fd0fb1e31c9b8b34ae71716c51a8e8'/>
<id>bde79c0e27fd0fb1e31c9b8b34ae71716c51a8e8</id>
<content type='text'>
The usual changes, added more references to OpenMP specs.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The usual changes, added more references to OpenMP specs.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Use new modifiers with AFFINITY/ALIGNED/DEVICE (#117786)</title>
<updated>2024-12-02T16:46:06+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-12-02T16:46:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=05096590e0ce68bdc6d32aac9ddbe8728e7514ae'/>
<id>05096590e0ce68bdc6d32aac9ddbe8728e7514ae</id>
<content type='text'>
This is a mostly mechanical change from specific modifiers embedded
directly in a clause to the Modifier variant.

Additional comments and references to the OpenMP specs were added.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a mostly mechanical change from specific modifiers embedded
directly in a clause to the Modifier variant.

Additional comments and references to the OpenMP specs were added.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Rename some `Type` members in OpenMP clauses (#117784)</title>
<updated>2024-12-02T15:22:30+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-12-02T15:22:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=608f4ae113f94b0c4a9b3c944a2aa9f115a805b4'/>
<id>608f4ae113f94b0c4a9b3c944a2aa9f115a805b4</id>
<content type='text'>
The intent is to keep names in sync with the terminology from the OpenMP
spec:
```
  OmpBindClause::Type       -&gt; Binding
  OmpDefaultClause::Type    -&gt; DataSharingAttribute
  OmpDeviceTypeClause::Type -&gt; DeviceTypeDescription
  OmpProcBindClause::Type   -&gt; AffinityPolicy
```
Add more comments with references to the OpenMP specs.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The intent is to keep names in sync with the terminology from the OpenMP
spec:
```
  OmpBindClause::Type       -&gt; Binding
  OmpDefaultClause::Type    -&gt; DataSharingAttribute
  OmpDeviceTypeClause::Type -&gt; DeviceTypeDescription
  OmpProcBindClause::Type   -&gt; AffinityPolicy
```
Add more comments with references to the OpenMP specs.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Use new modifiers in ALLOCATE clause (#117627)</title>
<updated>2024-12-02T14:11:49+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-12-02T14:11:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cdbd22876b71acad9e5eeceadc0d8859e6e73b18'/>
<id>cdbd22876b71acad9e5eeceadc0d8859e6e73b18</id>
<content type='text'>
Again, this simplifies the semantic checks and lowering quite a bit.
Update the check for positive alignment to use a more informative
message, and to highlight the modifier itsef, not the whole clause.
Remove the checks for the allocator expression itself being positive:
there is nothing in the spec that says that it should be positive.

Remove the "simple" modifier from the AllocateT template, since both
simple and complex modifiers are the same thing, only differing in
syntax.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Again, this simplifies the semantic checks and lowering quite a bit.
Update the check for positive alignment to use a more informative
message, and to highlight the modifier itsef, not the whole clause.
Remove the checks for the allocator expression itself being positive:
there is nothing in the spec that says that it should be positive.

Remove the "simple" modifier from the AllocateT template, since both
simple and complex modifiers are the same thing, only differing in
syntax.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Use new modifier infrastructure for MAP/FROM/TO clauses (#117447)</title>
<updated>2024-11-25T13:38:12+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-11-25T13:38:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=52755ac2531529369f1f29b9d0b29645f304f389'/>
<id>52755ac2531529369f1f29b9d0b29645f304f389</id>
<content type='text'>
This removes the specialized parsers and helper classes for these
clauses, namely ConcatSeparated, MapModifiers, and MotionModifiers. Map
and the motion clauses are now handled in the same way as all other
clauses with modifiers, with one exception: the commas separating their
modifiers are optional. This syntax is deprecated in OpenMP 5.2.

Implement version checks for modifiers: for a given modifier on a given
clause, check if that modifier is allowed on this clause in the
specified OpenMP version. This replaced several individual checks.

Add a testcase for handling map modifiers in a different order, and for
diagnosing an ultimate modifier out of position.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This removes the specialized parsers and helper classes for these
clauses, namely ConcatSeparated, MapModifiers, and MotionModifiers. Map
and the motion clauses are now handled in the same way as all other
clauses with modifiers, with one exception: the commas separating their
modifiers are optional. This syntax is deprecated in OpenMP 5.2.

Implement version checks for modifiers: for a given modifier on a given
clause, check if that modifier is allowed on this clause in the
specified OpenMP version. This replaced several individual checks.

Add a testcase for handling map modifiers in a different order, and for
diagnosing an ultimate modifier out of position.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Use new modifier code in ORDER and SCHEDULE clauses (#117081)</title>
<updated>2024-11-21T23:50:37+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-11-21T23:50:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e79cd2467622d6e388888a4e7ca2e9fbc3fbbc50'/>
<id>e79cd2467622d6e388888a4e7ca2e9fbc3fbbc50</id>
<content type='text'>
This actually simplifies the AST node for the schedule clause: the two
allowed modifiers can be easily classified as the ordering-modifier and
the chunk-modifier during parsing without the need to create additional
classes.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This actually simplifies the AST node for the schedule clause: the two
allowed modifiers can be easily classified as the ordering-modifier and
the chunk-modifier during parsing without the need to create additional
classes.</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Apply modifier representation to semantic checks (#116658)</title>
<updated>2024-11-21T19:18:01+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-11-21T19:18:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4fc1141e7650901b34cc8eec0c770e9015204087'/>
<id>4fc1141e7650901b34cc8eec0c770e9015204087</id>
<content type='text'>
Also, define helper macros in parse-tree.h.

Apply the new modifier representation to the DEFAULTMAP and REDUCTION
clauses, with testcases utilizing the new modifier validation.

OpenMP modifier overhaul: #3/3</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Also, define helper macros in parse-tree.h.

Apply the new modifier representation to the DEFAULTMAP and REDUCTION
clauses, with testcases utilizing the new modifier validation.

OpenMP modifier overhaul: #3/3</pre>
</div>
</content>
</entry>
<entry>
<title>[flang][OpenMP] Normalize clause modifiers that exist on their own (#116655)</title>
<updated>2024-11-20T14:33:17+00:00</updated>
<author>
<name>Krzysztof Parzyszek</name>
<email>Krzysztof.Parzyszek@amd.com</email>
</author>
<published>2024-11-20T14:33:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cfd67c214938a1f4ab3eff45a79a5a3da543d4b6'/>
<id>cfd67c214938a1f4ab3eff45a79a5a3da543d4b6</id>
<content type='text'>
This is the first part of the effort to make parsing of clause modifiers
more uniform and robust. Currently, when multiple modifiers are allowed,
the parser will expect them to appear in a hard-coded order.
Additionally, modifier properties (such as "ultimate") are checked
separately for each case.

The overall plan is
1. Extract all modifiers into their own top-level classes, and then
equip them with sets of common properties that will allow performing the
property checks generically, without refering to the specific kind of
the modifier.
2. Define a parser (as a separate class) for each modifier.
3. For each clause define a union (std::variant) of all allowable
modifiers, and parse the modifiers as a list of these unions.

The intent is also to isolate parts of the code that could eventually be
auto-generated.

OpenMP modifier overhaul: #1/3</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is the first part of the effort to make parsing of clause modifiers
more uniform and robust. Currently, when multiple modifiers are allowed,
the parser will expect them to appear in a hard-coded order.
Additionally, modifier properties (such as "ultimate") are checked
separately for each case.

The overall plan is
1. Extract all modifiers into their own top-level classes, and then
equip them with sets of common properties that will allow performing the
property checks generically, without refering to the specific kind of
the modifier.
2. Define a parser (as a separate class) for each modifier.
3. For each clause define a union (std::variant) of all allowable
modifiers, and parse the modifiers as a list of these unions.

The intent is also to isolate parts of the code that could eventually be
auto-generated.

OpenMP modifier overhaul: #1/3</pre>
</div>
</content>
</entry>
</feed>
