<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/clang/include/module.modulemap, 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>Reland "[clang] Refactor option-related code from clangDriver into new clangOptions library" (#167374)</title>
<updated>2025-11-10T20:24:39+00:00</updated>
<author>
<name>Naveen Seth Hanig</name>
<email>naveen.hanig@outlook.com</email>
</author>
<published>2025-11-10T20:24:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f63d33da0a517a9a7096e0e67defb50c5995dd41'/>
<id>f63d33da0a517a9a7096e0e67defb50c5995dd41</id>
<content type='text'>
This relands #167348.

The original PR was reverted due to a reported build failure, which was
later diagnosed as a local issue in the developer’s checkout or build
state. See discussion here:
https://github.com/llvm/llvm-project/pull/163659#discussion_r2511546964

No additional changes have been made in this reland.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This relands #167348.

The original PR was reverted due to a reported build failure, which was
later diagnosed as a local issue in the developer’s checkout or build
state. See discussion here:
https://github.com/llvm/llvm-project/pull/163659#discussion_r2511546964

No additional changes have been made in this reland.</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[clang] Refactor option-related code from clangDriver into new clangOptions library" (#167348)</title>
<updated>2025-11-10T17:27:20+00:00</updated>
<author>
<name>Naveen Seth Hanig</name>
<email>naveen.hanig@outlook.com</email>
</author>
<published>2025-11-10T17:27:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6bad2d139bd08c657620bb152113f9e957c582c5'/>
<id>6bad2d139bd08c657620bb152113f9e957c582c5</id>
<content type='text'>
Reverts #163659 due to missing one reference clang/Driver/Options.h in 
clang/include/clang/Driver/Driver.h.

See https://github.com/llvm/llvm-project/pull/163659#issuecomment-3512979187</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts #163659 due to missing one reference clang/Driver/Options.h in 
clang/include/clang/Driver/Driver.h.

See https://github.com/llvm/llvm-project/pull/163659#issuecomment-3512979187</pre>
</div>
</content>
</entry>
<entry>
<title>[clang] Refactor option-related code from clangDriver into new clangOptions library (#163659)</title>
<updated>2025-11-10T16:19:03+00:00</updated>
<author>
<name>Naveen Seth Hanig</name>
<email>naveen.hanig@outlook.com</email>
</author>
<published>2025-11-10T16:19:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9a783b63e647d95e001f55464a9bc7fa0c3929c3'/>
<id>9a783b63e647d95e001f55464a9bc7fa0c3929c3</id>
<content type='text'>
This change moves option-related code from clangDriver into a new
clangOptions library.

This refactoring is part of a broader effort to support driver-managed
builds for compilations using C++ named modules and/or Clang modules.
It is required for linking the dependency scanning tooling against the
driver without introducing cyclic dependencies, which would otherwise
cause build failures when dynamic linking is enabled.
In particular, clangFrontend must no longer depend on clangDriver
for this to be possible.

This PR is motivated by the following review comment:
https://github.com/llvm/llvm-project/pull/152770#discussion_r2430756918</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This change moves option-related code from clangDriver into a new
clangOptions library.

This refactoring is part of a broader effort to support driver-managed
builds for compilations using C++ named modules and/or Clang modules.
It is required for linking the dependency scanning tooling against the
driver without introducing cyclic dependencies, which would otherwise
cause build failures when dynamic linking is enabled.
In particular, clangFrontend must no longer depend on clangDriver
for this to be possible.

This PR is motivated by the following review comment:
https://github.com/llvm/llvm-project/pull/152770#discussion_r2430756918</pre>
</div>
</content>
</entry>
<entry>
<title>[clang] Fix clang module build by declaring new textual header (#155510)</title>
<updated>2025-08-26T22:51:44+00:00</updated>
<author>
<name>Steven Wu</name>
<email>stevenwu@apple.com</email>
</author>
<published>2025-08-26T22:51:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5313d6895cd1153109f35cfdb60fbb6348f68cb9'/>
<id>5313d6895cd1153109f35cfdb60fbb6348f68cb9</id>
<content type='text'>
Add `clang/Basic/ABIVersions.def` introduced in #151995 to textual
header
to fix clang module build.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add `clang/Basic/ABIVersions.def` introduced in #151995 to textual
header
to fix clang module build.</pre>
</div>
</content>
</entry>
<entry>
<title>[AArch64] Rename AArch64SVEACLETypes.def and add base SVE_TYPE.</title>
<updated>2025-05-28T11:26:54+00:00</updated>
<author>
<name>David Green</name>
<email>david.green@arm.com</email>
</author>
<published>2025-05-28T11:26:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3a42cbd47d3e92b8794378d2a0e8ec7ae81950d7'/>
<id>3a42cbd47d3e92b8794378d2a0e8ec7ae81950d7</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[Modules] Add `clang/Lex/HLSLRootSignatureTokenKinds.def` to clang's `modulemap` (#127839)</title>
<updated>2025-02-19T19:21:04+00:00</updated>
<author>
<name>Qiongsi Wu</name>
<email>qiongsiwu@gmail.com</email>
</author>
<published>2025-02-19T19:21:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=85e23fe9c71f97280c804a139c3d014092b30c7f'/>
<id>85e23fe9c71f97280c804a139c3d014092b30c7f</id>
<content type='text'>
b41b86a907f653f79bab10d4c80b3a41d146c71b added a new textual header
`clang/Lex/HLSLRootSignatureTokenKinds.def` but did not add it to
`clang`'s module map. This causes build failure when building llvm with
`-DLLVM_ENABLE_MODULES=ON`. This PR adds the new textual header to the
module map and fixes the build break.

Fixing rdar://145148093.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
b41b86a907f653f79bab10d4c80b3a41d146c71b added a new textual header
`clang/Lex/HLSLRootSignatureTokenKinds.def` but did not add it to
`clang`'s module map. This causes build failure when building llvm with
`-DLLVM_ENABLE_MODULES=ON`. This PR adds the new textual header to the
module map and fixes the build break.

Fixing rdar://145148093.</pre>
</div>
</content>
</entry>
<entry>
<title>[StrTable] Fix modules build and clean up stale files (#125979)</title>
<updated>2025-02-06T21:21:34+00:00</updated>
<author>
<name>Chandler Carruth</name>
<email>chandlerc@gmail.com</email>
</author>
<published>2025-02-06T21:21:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=da083e282cc1704c85b1724ae9b9f9d1b4cf5668'/>
<id>da083e282cc1704c85b1724ae9b9f9d1b4cf5668</id>
<content type='text'>
I missed a few places to tidy up from before using the tablengen files
directly for the builtins. I didn't remove all of the modulemap entries
and there were two small `.def` files left lingering. This should clean
all of that up. I went through to cross check the list of files and it
looks correct now.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I missed a few places to tidy up from before using the tablengen files
directly for the builtins. I didn't remove all of the modulemap entries
and there were two small `.def` files left lingering. This should clean
all of that up. I went through to cross check the list of files and it
looks correct now.</pre>
</div>
</content>
</entry>
<entry>
<title>[Modules] Fix missing module dependency introduced by 7347870 (#126007)</title>
<updated>2025-02-06T20:37:51+00:00</updated>
<author>
<name>Qiongsi Wu</name>
<email>qiongsiwu@gmail.com</email>
</author>
<published>2025-02-06T20:37:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b93f8b8a97193e38f393dc07bd7945d331558e23'/>
<id>b93f8b8a97193e38f393dc07bd7945d331558e23</id>
<content type='text'>
73478708839fad8b02b3cfc84959d64a15ba93ca introduced a textual header but
did not update clang's module map. This PR adds the header to the module
map.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
73478708839fad8b02b3cfc84959d64a15ba93ca introduced a textual header but
did not update clang's module map. This PR adds the header to the module
map.</pre>
</div>
</content>
</entry>
<entry>
<title>[StrTable] Switch Clang builtins to use string tables</title>
<updated>2025-02-04T18:04:57+00:00</updated>
<author>
<name>Chandler Carruth</name>
<email>chandlerc@gmail.com</email>
</author>
<published>2024-12-14T09:09:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cd269fee05a0f78fb53b65f701b4e06e9ddab424'/>
<id>cd269fee05a0f78fb53b65f701b4e06e9ddab424</id>
<content type='text'>
This both reapplies #118734, the initial attempt at this, and updates it
significantly.

First, it uses the newly added `StringTable` abstraction for string
tables, and simplifies the construction to build the string table and
info arrays separately. This should reduce any `constexpr` compile time
memory or CPU cost of the original PR while significantly improving the
APIs throughout.

It also restructures the builtins to support sharding across several
independent tables. This accomplishes two improvements from the
original PR:

1) It improves the APIs used significantly.

2) When builtins are defined from different sources (like SVE vs MVE in
   AArch64), this allows each of them to build their own string table
   independently rather than having to merge the string tables and info
   structures.

3) It allows each shard to factor out a common prefix, often cutting the
   size of the strings needed for the builtins by a factor two.

The second point is important both to allow different mechanisms of
construction (for example a `.def` file and a tablegen'ed `.inc` file,
or different tablegen'ed `.inc files), it also simply reduces the sizes
of these tables which is valuable given how large they are in some
cases. The third builds on that size reduction.

Initially, we use this new sharding rather than merging tables in
AArch64, LoongArch, RISCV, and X86. Mostly this helps ensure the system
works, as without further changes these still push scaling limits.
Subsequent commits will more deeply leverage the new structure,
including using the prefix capabilities which cannot be easily factored
out here and requires deep changes to the targets.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This both reapplies #118734, the initial attempt at this, and updates it
significantly.

First, it uses the newly added `StringTable` abstraction for string
tables, and simplifies the construction to build the string table and
info arrays separately. This should reduce any `constexpr` compile time
memory or CPU cost of the original PR while significantly improving the
APIs throughout.

It also restructures the builtins to support sharding across several
independent tables. This accomplishes two improvements from the
original PR:

1) It improves the APIs used significantly.

2) When builtins are defined from different sources (like SVE vs MVE in
   AArch64), this allows each of them to build their own string table
   independently rather than having to merge the string tables and info
   structures.

3) It allows each shard to factor out a common prefix, often cutting the
   size of the strings needed for the builtins by a factor two.

The second point is important both to allow different mechanisms of
construction (for example a `.def` file and a tablegen'ed `.inc` file,
or different tablegen'ed `.inc files), it also simply reduces the sizes
of these tables which is valuable given how large they are in some
cases. The third builds on that size reduction.

Initially, we use this new sharding rather than merging tables in
AArch64, LoongArch, RISCV, and X86. Mostly this helps ensure the system
works, as without further changes these still push scaling limits.
Subsequent commits will more deeply leverage the new structure,
including using the prefix capabilities which cannot be easily factored
out here and requires deep changes to the targets.
</pre>
</div>
</content>
</entry>
<entry>
<title>[StrTable] Mechanically convert Hexagon builtins to use TableGen (#123460)</title>
<updated>2025-01-28T08:07:38+00:00</updated>
<author>
<name>Chandler Carruth</name>
<email>chandlerc@gmail.com</email>
</author>
<published>2025-01-28T08:07:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7e22180c20fa3b4e0add41ad620d2eaac2b47fcc'/>
<id>7e22180c20fa3b4e0add41ad620d2eaac2b47fcc</id>
<content type='text'>
This switches them to use the common builtin TableGen emission.

The fancy feature string preprocessor tricks are replaced with a fairly
direct translation into TableGen.

All of the actual definitions were created using a quite hack-y Python
script that was never intended to be productionized. It preserves the
order, spacing, and even comments from the original files. For
posterity, the script used is here:

https://gist.github.com/chandlerc/f53c7d735e33eecf388529bd9a6010df

The original `.def` file appears to be generated by some out-of-tree
`iset.py` script, which because it is out of tree I couldn't update. It
should be very straightforward though to update it to generate a similar
structure as was used to produce the `.td` file.

In addition to helping move towards TableGen for all of the builtins,
these builtins in particular can be *much* more efficiently handled
using TableGen when we start emitting string tables for them because it
allows de-duplicating all of the feature strings.

The commit sha parent at the time the PR was made is
7253c6fde498c4c9470b681df47d46e6930d6a02 and at that commit, the
resulting TableGen file produces a `.inc` file that only differs in
whitespace and the order of the builtins defined.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This switches them to use the common builtin TableGen emission.

The fancy feature string preprocessor tricks are replaced with a fairly
direct translation into TableGen.

All of the actual definitions were created using a quite hack-y Python
script that was never intended to be productionized. It preserves the
order, spacing, and even comments from the original files. For
posterity, the script used is here:

https://gist.github.com/chandlerc/f53c7d735e33eecf388529bd9a6010df

The original `.def` file appears to be generated by some out-of-tree
`iset.py` script, which because it is out of tree I couldn't update. It
should be very straightforward though to update it to generate a similar
structure as was used to produce the `.td` file.

In addition to helping move towards TableGen for all of the builtins,
these builtins in particular can be *much* more efficiently handled
using TableGen when we start emitting string tables for them because it
allows de-duplicating all of the feature strings.

The commit sha parent at the time the PR was made is
7253c6fde498c4c9470b681df47d46e6930d6a02 and at that commit, the
resulting TableGen file produces a `.inc` file that only differs in
whitespace and the order of the builtins defined.</pre>
</div>
</content>
</entry>
</feed>
