<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/clang/lib/CodeGen/ModuleBuilder.cpp, branch users/nico/python-1</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>[CodeGen] Use range-based for loops (NFC) (#145142)</title>
<updated>2025-06-21T15:20:57+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-06-21T15:20:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ae372bfca890cc7a67553b3cb19134359b66c0e1'/>
<id>ae372bfca890cc7a67553b3cb19134359b66c0e1</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[IR] Store Triple in Module (NFC) (#129868)</title>
<updated>2025-03-06T09:27:47+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2025-03-06T09:27:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=979c275097a642e9b96c6b0a12f013c831af3a6e'/>
<id>979c275097a642e9b96c6b0a12f013c831af3a6e</id>
<content type='text'>
The module currently stores the target triple as a string. This means
that any code that wants to actually use the triple first has to
instantiate a Triple, which is somewhat expensive. The change in #121652
caused a moderate compile-time regression due to this. While it would be
easy enough to work around, I think that architecturally, it makes more
sense to store the parsed Triple in the module, so that it can always be
directly queried.

For this change, I've opted not to add any magic conversions between
std::string and Triple for backwards-compatibilty purses, and instead
write out needed Triple()s or str()s explicitly. This is because I think
a decent number of them should be changed to work on Triple as well, to
avoid unnecessary conversions back and forth.

The only interesting part in this patch is that the default triple is
Triple("") instead of Triple() to preserve existing behavior. The former
defaults to using the ELF object format instead of unknown object
format. We should fix that as well.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The module currently stores the target triple as a string. This means
that any code that wants to actually use the triple first has to
instantiate a Triple, which is somewhat expensive. The change in #121652
caused a moderate compile-time regression due to this. While it would be
easy enough to work around, I think that architecturally, it makes more
sense to store the parsed Triple in the module, so that it can always be
directly queried.

For this change, I've opted not to add any magic conversions between
std::string and Triple for backwards-compatibilty purses, and instead
write out needed Triple()s or str()s explicitly. This is because I think
a decent number of them should be changed to work on Triple as well, to
avoid unnecessary conversions back and forth.

The only interesting part in this patch is that the default triple is
Triple("") instead of Triple() to preserve existing behavior. The former
defaults to using the ELF object format instead of unknown object
format. We should fix that as well.</pre>
</div>
</content>
</entry>
<entry>
<title>[BPF] Fix linking issues in static map initializers (#91310)</title>
<updated>2024-07-05T14:32:09+00:00</updated>
<author>
<name>Nick Zavaritsky</name>
<email>mejedi@gmail.com</email>
</author>
<published>2024-07-05T14:32:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ae0d2244a23567c8d9863e63b338d34c31416a7b'/>
<id>ae0d2244a23567c8d9863e63b338d34c31416a7b</id>
<content type='text'>
When BPF object files are linked with bpftool, every symbol must be
accompanied by BTF info. Ensure that extern functions referenced by
global variable initializers are included in BTF.

The primary motivation is "static" initialization of PROG maps:

```c
extern int elsewhere(struct xdp_md *);

struct {
  __uint(type, BPF_MAP_TYPE_PROG_ARRAY);
  __uint(max_entries, 1);
  __type(key, int);
  __type(value, int);
  __array(values, int (struct xdp_md *));
} prog_map SEC(".maps") = { .values = { elsewhere } };
```

BPF backend needs debug info to produce BTF. Debug info is not
normally generated for external variables and functions. Previously, it
was solved differently for variables (collecting variable declarations
    in ExternalDeclarations vector) and functions (logic invoked during
    codegen in CGExpr.cpp).

This patch generalises ExternalDefclarations to include both function
and variable declarations. This change ensures that function references
    are not missed no matter the context. Previously external functions
    referenced in constant expressions lacked debug info.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When BPF object files are linked with bpftool, every symbol must be
accompanied by BTF info. Ensure that extern functions referenced by
global variable initializers are included in BTF.

The primary motivation is "static" initialization of PROG maps:

```c
extern int elsewhere(struct xdp_md *);

struct {
  __uint(type, BPF_MAP_TYPE_PROG_ARRAY);
  __uint(max_entries, 1);
  __type(key, int);
  __type(value, int);
  __array(values, int (struct xdp_md *));
} prog_map SEC(".maps") = { .values = { elsewhere } };
```

BPF backend needs debug info to produce BTF. Debug info is not
normally generated for external variables and functions. Previously, it
was solved differently for variables (collecting variable declarations
    in ExternalDeclarations vector) and functions (logic invoked during
    codegen in CGExpr.cpp).

This patch generalises ExternalDefclarations to include both function
and variable declarations. This change ensures that function references
    are not missed no matter the context. Previously external functions
    referenced in constant expressions lacked debug info.</pre>
</div>
</content>
</entry>
<entry>
<title>[AArch64] Add soft-float ABI (#84146)</title>
<updated>2024-03-19T13:58:51+00:00</updated>
<author>
<name>ostannard</name>
<email>oliver.stannard@arm.com</email>
</author>
<published>2024-03-19T13:58:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ef395a492aa931f428e99e1c0a93d4ad2fb0fcfa'/>
<id>ef395a492aa931f428e99e1c0a93d4ad2fb0fcfa</id>
<content type='text'>
This is re-working of #74460, which adds a soft-float ABI for AArch64.
That was reverted because it causes errors when building the linux and
fuchsia kernels.

The problem is that GCC's implementation of the ABI compatibility checks
when using the hard-float ABI on a target without FP registers does it's
checks after optimisation. The previous version of this patch reported
errors for all uses of floating-point types, which is stricter than what
GCC does in practice.

This changes two things compared to the first version:
* Only check the types of function arguments and returns, not the types
of other values. This is more relaxed than GCC, while still guaranteeing
ABI compatibility.
* Move the check from Sema to CodeGen, so that inline functions are only
checked if they are actually used. There are some cases in the linux
kernel which depend on this behaviour of GCC.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is re-working of #74460, which adds a soft-float ABI for AArch64.
That was reverted because it causes errors when building the linux and
fuchsia kernels.

The problem is that GCC's implementation of the ABI compatibility checks
when using the hard-float ABI on a target without FP registers does it's
checks after optimisation. The previous version of this patch reported
errors for all uses of floating-point types, which is stricter than what
GCC does in practice.

This changes two things compared to the first version:
* Only check the types of function arguments and returns, not the types
of other values. This is more relaxed than GCC, while still guaranteeing
ABI compatibility.
* Move the check from Sema to CodeGen, so that inline functions are only
checked if they are actually used. There are some cases in the linux
kernel which depend on this behaviour of GCC.</pre>
</div>
</content>
</entry>
<entry>
<title>[clang-repl][CUDA] Re-land: Initial interactive CUDA support for clang-repl</title>
<updated>2023-05-27T08:24:42+00:00</updated>
<author>
<name>Anubhab Ghosh</name>
<email>anubhabghosh.me@gmail.com</email>
</author>
<published>2023-03-06T11:20:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ddeab07ca63235f8d952e1171b56fdb0f2d761c9'/>
<id>ddeab07ca63235f8d952e1171b56fdb0f2d761c9</id>
<content type='text'>
CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.

Differential Revision: https://reviews.llvm.org/D146389
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.

Differential Revision: https://reviews.llvm.org/D146389
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[clang-repl][CUDA] Initial interactive CUDA support for clang-repl"</title>
<updated>2023-05-20T09:10:04+00:00</updated>
<author>
<name>Anubhab Ghosh</name>
<email>anubhabghosh.me@gmail.com</email>
</author>
<published>2023-05-20T09:10:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0929f5b90350aa2f9175d7e1094b1750535c0e44'/>
<id>0929f5b90350aa2f9175d7e1094b1750535c0e44</id>
<content type='text'>
This reverts commit 80e7eed6a610ab3c7289e6f9b7ec006bc7d7ae31.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 80e7eed6a610ab3c7289e6f9b7ec006bc7d7ae31.
</pre>
</div>
</content>
</entry>
<entry>
<title>[clang-repl][CUDA] Initial interactive CUDA support for clang-repl</title>
<updated>2023-05-20T08:30:48+00:00</updated>
<author>
<name>Anubhab Ghosh</name>
<email>anubhabghosh.me@gmail.com</email>
</author>
<published>2023-03-06T11:20:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=80e7eed6a610ab3c7289e6f9b7ec006bc7d7ae31'/>
<id>80e7eed6a610ab3c7289e6f9b7ec006bc7d7ae31</id>
<content type='text'>
CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.

Differential Revision: https://reviews.llvm.org/D146389
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.

Differential Revision: https://reviews.llvm.org/D146389
</pre>
</div>
</content>
</entry>
<entry>
<title>[clang-repl] Support statements on global scope in incremental mode.</title>
<updated>2022-12-03T07:18:07+00:00</updated>
<author>
<name>Vassil Vassilev</name>
<email>v.g.vassilev@gmail.com</email>
</author>
<published>2022-06-08T09:59:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=dc4889357adb1b909b986b7d2f2a4b9a2cc40c8e'/>
<id>dc4889357adb1b909b986b7d2f2a4b9a2cc40c8e</id>
<content type='text'>
This patch teaches clang to parse statements on the global scope to allow:
```
./bin/clang-repl
clang-repl&gt; int i = 12;
clang-repl&gt; ++i;
clang-repl&gt; extern "C" int printf(const char*,...);
clang-repl&gt; printf("%d\n", i);
13
clang-repl&gt; %quit
```

Generally, disambiguating between statements and declarations is a non-trivial
task for a C++ parser. The challenge is to allow both standard C++ to be
translated as if this patch does not exist and in the cases where the user typed
a statement to be executed as if it were in a function body.

Clang's Parser does pretty well in disambiguating between declarations and
expressions. We have added DisambiguatingWithExpression flag which allows us to
preserve the existing and optimized behavior where needed and implement the
extra rules for disambiguating. Only few cases require additional attention:
  * Constructors/destructors -- Parser::isConstructorDeclarator was used in to
    disambiguate between ctor-looking declarations and statements on the global
    scope(eg. `Ns::f()`).
  * The template keyword -- the template keyword can appear in both declarations
    and statements. This patch considers the template keyword to be a declaration
    starter which breaks a few cases in incremental mode which will be tackled
    later.
  * The inline (and similar) keyword -- looking at the first token in many cases
    allows us to classify what is a declaration.
  * Other language keywords and specifiers -- ObjC/ObjC++/OpenCL/OpenMP rely on
    pragmas or special tokens which will be handled in subsequent patches.

The patch conceptually models a "top-level" statement into a TopLevelStmtDecl.
The TopLevelStmtDecl is lowered into a void function with no arguments.
We attach this function to the global initializer list to execute the statement
blocks in the correct order.

Differential revision: https://reviews.llvm.org/D127284
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch teaches clang to parse statements on the global scope to allow:
```
./bin/clang-repl
clang-repl&gt; int i = 12;
clang-repl&gt; ++i;
clang-repl&gt; extern "C" int printf(const char*,...);
clang-repl&gt; printf("%d\n", i);
13
clang-repl&gt; %quit
```

Generally, disambiguating between statements and declarations is a non-trivial
task for a C++ parser. The challenge is to allow both standard C++ to be
translated as if this patch does not exist and in the cases where the user typed
a statement to be executed as if it were in a function body.

Clang's Parser does pretty well in disambiguating between declarations and
expressions. We have added DisambiguatingWithExpression flag which allows us to
preserve the existing and optimized behavior where needed and implement the
extra rules for disambiguating. Only few cases require additional attention:
  * Constructors/destructors -- Parser::isConstructorDeclarator was used in to
    disambiguate between ctor-looking declarations and statements on the global
    scope(eg. `Ns::f()`).
  * The template keyword -- the template keyword can appear in both declarations
    and statements. This patch considers the template keyword to be a declaration
    starter which breaks a few cases in incremental mode which will be tackled
    later.
  * The inline (and similar) keyword -- looking at the first token in many cases
    allows us to classify what is a declaration.
  * Other language keywords and specifiers -- ObjC/ObjC++/OpenCL/OpenMP rely on
    pragmas or special tokens which will be handled in subsequent patches.

The patch conceptually models a "top-level" statement into a TopLevelStmtDecl.
The TopLevelStmtDecl is lowered into a void function with no arguments.
We attach this function to the global initializer list to execute the statement
blocks in the correct order.

Differential revision: https://reviews.llvm.org/D127284
</pre>
</div>
</content>
</entry>
<entry>
<title>[CGDebugInfo] Access the current working directory from the `VFS`</title>
<updated>2022-07-26T20:48:39+00:00</updated>
<author>
<name>Argyrios Kyrtzidis</name>
<email>kyrtzidis@apple.com</email>
</author>
<published>2022-07-23T07:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8dfaecc4c24494337933aff9d9166486ca0949f1'/>
<id>8dfaecc4c24494337933aff9d9166486ca0949f1</id>
<content type='text'>
...instead of calling `llvm::sys::fs::current_path()` directly.

Differential Revision: https://reviews.llvm.org/D130443
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
...instead of calling `llvm::sys::fs::current_path()` directly.

Differential Revision: https://reviews.llvm.org/D130443
</pre>
</div>
</content>
</entry>
<entry>
<title>Reland "[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder"</title>
<updated>2022-06-18T12:27:21+00:00</updated>
<author>
<name>Jun Zhang</name>
<email>jun@junz.org</email>
</author>
<published>2022-06-18T11:53:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=cd64a427efa0baaf1bb7ae624d4301908afc07f7'/>
<id>cd64a427efa0baaf1bb7ae624d4301908afc07f7</id>
<content type='text'>
This reverts commits:
d3ddc251acae631bf5ab4da13878f7e8b5b5a451
d90eecff5c9e7e9f8263de6cd72d70322400829f

It turned out there're some options turned on that leaks the memory
intentionally, which fires the asan builds after the patch being
applied. The issue has been fixed in
7bc00ce5cd41aad5fd0775f58c8e85a0a8d9ee56, so reland it.

Below is the original commit message:

The intent of this patch is to selectively carry some states over to
the Builder so we won't lose the information of the previous symbols.

This used to be several downstream patches of Cling, it aims to fix
errors in Clang Interpreter when trying to use inline functions.
Before this patch:

clang-repl&gt; inline int foo() { return 42;}
clang-repl&gt; int x = foo();

JIT session error: Symbols not found: [ _Z3foov ]
error: Failed to materialize symbols:
{ (main, { x, $.incr_module_1.__inits.0, __orc_init_func.incr_module_1 }) }

Co-authored-by: Axel Naumann &lt;Axel.Naumann@cern.ch&gt;
Signed-off-by: Jun Zhang &lt;jun@junz.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commits:
d3ddc251acae631bf5ab4da13878f7e8b5b5a451
d90eecff5c9e7e9f8263de6cd72d70322400829f

It turned out there're some options turned on that leaks the memory
intentionally, which fires the asan builds after the patch being
applied. The issue has been fixed in
7bc00ce5cd41aad5fd0775f58c8e85a0a8d9ee56, so reland it.

Below is the original commit message:

The intent of this patch is to selectively carry some states over to
the Builder so we won't lose the information of the previous symbols.

This used to be several downstream patches of Cling, it aims to fix
errors in Clang Interpreter when trying to use inline functions.
Before this patch:

clang-repl&gt; inline int foo() { return 42;}
clang-repl&gt; int x = foo();

JIT session error: Symbols not found: [ _Z3foov ]
error: Failed to materialize symbols:
{ (main, { x, $.incr_module_1.__inits.0, __orc_init_func.incr_module_1 }) }

Co-authored-by: Axel Naumann &lt;Axel.Naumann@cern.ch&gt;
Signed-off-by: Jun Zhang &lt;jun@junz.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
