[CGDebugInfo] Access the current working directory from the `VFS`

...instead of calling `llvm::sys::fs::current_path()` directly.

Differential Revision: https://reviews.llvm.org/D130443

[NFC] Move function definition to cpp file

Signed-off-by: Jun Zhang <[email protected]>

re-land [C++20][Modules] Build module static initializers per P1874R1.

The re-land fixes module map module dependencies seen on Greendragon, but
not in the clang test suite.

---

Currently we only

re-land [C++20][Modules] Build module static initializers per P1874R1.

The re-land fixes module map module dependencies seen on Greendragon, but
not in the clang test suite.

---

Currently we only implement this for the Itanium ABI since the correct
mangling for the initializers in other ABIs is not yet known.

Intended result:

For a module interface [which includes partition interface and implementation
units] (instead of the generic CXX initializer) we emit a module init that:

- wraps the contained initializations in a control variable to ensure that
the inits only happen once, even if a module is imported many times by
imports of the main unit.

- calls module initializers for imported modules first. Note that the
order of module import is not significant, and therefore neither is the
order of imported module initializers.

- We then call initializers for the Global Module Fragment (if present)
- We then call initializers for the current module.
- We then call initializers for the Private Module Fragment (if present)

For a module implementation unit, or a non-module TU that imports at least one
module we emit a regular CXX init that:

- Calls the initializers for any imported modules first.
- Then proceeds as normal with remaining inits.

For all module unit kinds we include a global constructor entry, this allows
for the (in most cases unusual) possibility that a module object could be
included in a final binary without a specific call to its initializer.

Implementation:

- We provide the module pointer in the AST Context so that CodeGen can act
on it and its sub-modules.

- We need to account for module build lines like this:
` clang -cc1 -std=c++20 Foo.pcm -emit-obj -o Foo.o` or
` clang -cc1 -std=c++20 -xc++-module Foo.cpp -emit-obj -o Foo.o`

- in order to do this, we add to ParseAST to set the module pointer in
the ASTContext, once we establish that this is a module build and we
know the module pointer. To be able to do this, we make the query for
current module public in Sema.

- In CodeGen, we determine if the current build requires a CXX20-style module
init and, if so, we defer any module initializers during the "Eagerly
Emitted" phase.

- We then walk the module initializers at the end of the TU but before
emitting deferred inits (which adds any hidden and static ones, fixing
https://github.com/llvm/llvm-project/issues/51873 ).

- We then proceed to emit the deferred inits and continue to emit the CXX
init function.

Differential Revision: https://reviews.llvm.org/D126189

show more ...

[InstrProf] Add options to profile function groups

Add two options, `-fprofile-function-groups=N` and `-fprofile-selected-function-group=i` used to partition functions into `N` groups and only instr

[InstrProf] Add options to profile function groups

Add two options, `-fprofile-function-groups=N` and `-fprofile-selected-function-group=i` used to partition functions into `N` groups and only instrument the functions in group `i`. Similar options were added to xray in https://reviews.llvm.org/D87953 and the goal is the same; to reduce instrumented size overhead by spreading the overhead across multiple builds. Raw profiles from different groups can be added like normal using the `llvm-profdata merge` command.

Reviewed By: ianlevesque

Differential Revision: https://reviews.llvm.org/D129594

show more ...

[CodeGen] Keep track of decls that were deferred and have been emitted.

This patch adds a new field called EmittedDeferredDecls in CodeGenModule
that keeps track of decls that were deferred and have

[CodeGen] Keep track of decls that were deferred and have been emitted.

This patch adds a new field called EmittedDeferredDecls in CodeGenModule
that keeps track of decls that were deferred and have been emitted.

The intention of this patch is to solve issues in the incremental c++,
we'll lose info of decls that are lazily emitted when we undo their
usage.

See example below:

clang-repl> inline int foo() { return 42;}
clang-repl> int bar = foo();
clang-repl> %undo
clang-repl> int baz = foo();
JIT session error: Symbols not found: [ _Z3foov ]
error: Failed to materialize symbols: { (main, { baz, $.incr_module_2.inits.0,
orc_init_func.incr_module_2 }) }

Signed-off-by: Jun Zhang <[email protected]>

Differential Revision: https://reviews.llvm.org/D128782

show more ...

Revert "[C++20][Modules] Build module static initializers per P1874R1."

This reverts commit ac507102d258b6fc0cb57eb60c9dfabd57ff562f.

reverting while we figuere out why one of the green dragon lldb

Revert "[C++20][Modules] Build module static initializers per P1874R1."

This reverts commit ac507102d258b6fc0cb57eb60c9dfabd57ff562f.

reverting while we figuere out why one of the green dragon lldb test fails.

show more ...

[C++20][Modules] Build module static initializers per P1874R1.

Currently we only implement this for the Itanium ABI since the correct
mangling for the initializers in other ABIs is not yet known.

I

[C++20][Modules] Build module static initializers per P1874R1.

Currently we only implement this for the Itanium ABI since the correct
mangling for the initializers in other ABIs is not yet known.

Intended result:

For a module interface [which includes partition interface and implementation
units] (instead of the generic CXX initializer) we emit a module init that:

- wraps the contained initializations in a control variable to ensure that
the inits only happen once, even if a module is imported many times by
imports of the main unit.

- calls module initializers for imported modules first. Note that the
order of module import is not significant, and therefore neither is the
order of imported module initializers.

- We then call initializers for the Global Module Fragment (if present)
- We then call initializers for the current module.
- We then call initializers for the Private Module Fragment (if present)

For a module implementation unit, or a non-module TU that imports at least one
module we emit a regular CXX init that:

- Calls the initializers for any imported modules first.
- Then proceeds as normal with remaining inits.

For all module unit kinds we include a global constructor entry, this allows
for the (in most cases unusual) possibility that a module object could be
included in a final binary without a specific call to its initializer.

Implementation:

- We provide the module pointer in the AST Context so that CodeGen can act
on it and its sub-modules.

- We need to account for module build lines like this:
` clang -cc1 -std=c++20 Foo.pcm -emit-obj -o Foo.o` or
` clang -cc1 -std=c++20 -xc++-module Foo.cpp -emit-obj -o Foo.o`

- in order to do this, we add to ParseAST to set the module pointer in
the ASTContext, once we establish that this is a module build and we
know the module pointer. To be able to do this, we make the query for
current module public in Sema.

- In CodeGen, we determine if the current build requires a CXX20-style module
init and, if so, we defer any module initializers during the "Eagerly
Emitted" phase.

- We then walk the module initializers at the end of the TU but before
emitting deferred inits (which adds any hidden and static ones, fixing
https://github.com/llvm/llvm-project/issues/51873 ).

- We then proceed to emit the deferred inits and continue to emit the CXX
init function.

Differential Revision: https://reviews.llvm.org/D126189

show more ...

[ubsan] Using metadata instead of prologue data for function sanitizer

Information in the function `Prologue Data` is intentionally opaque.
When a function with `Prologue Data` is duplicated. The se

[ubsan] Using metadata instead of prologue data for function sanitizer

Information in the function `Prologue Data` is intentionally opaque.
When a function with `Prologue Data` is duplicated. The self (global
value) references inside `Prologue Data` is still pointing to the
original function. This may cause errors like `fatal error: error in backend: Cannot represent a difference across sections`.

This patch detaches the information from function `Prologue Data`
and attaches it to a function metadata node.

This and D116130 fix https://github.com/llvm/llvm-project/issues/49689.

Reviewed By: pcc

Differential Revision: https://reviews.llvm.org/D115844

show more ...

[HIP] add -fhip-kernel-arg-name

Add option -fhip-kernel-arg-name to emit kernel argument
name metadata, which is needed for certain HIP applications.

Reviewed by: Artem Belevich, Fangrui Song, Bria

[HIP] add -fhip-kernel-arg-name

Add option -fhip-kernel-arg-name to emit kernel argument
name metadata, which is needed for certain HIP applications.

Reviewed by: Artem Belevich, Fangrui Song, Brian Sumner

Differential Revision: https://reviews.llvm.org/D128022

show more ...

Reland "[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder"

This reverts commits:
d3ddc251acae631bf5ab4da13878f7e8b5b5a451
d90eecff5c9e7e9f8263de6cd72d70322400829f

It turned out the

Reland "[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder"

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> inline int foo() { return 42;}
clang-repl> 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 <[email protected]>
Signed-off-by: Jun Zhang <[email protected]>

show more ...

[clang] Don't emit type test/assume for virtual classes that should never participate in WPD

Reviewed By: pcc

Differential Revision: https://reviews.llvm.org/D127876

Revert "Reland "[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder""

This reverts commit 781ee538da1855876b085989a37ec959e3f2ecd1.

Asan build is still broken :(

Reland "[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder"

This reverts commits:
d3ddc251acae631bf5ab4da13878f7e8b5b5a451
d90eecff5c9e7e9f8263de6cd72d70322400829f

This relands belo

Reland "[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder"

This reverts commits:
d3ddc251acae631bf5ab4da13878f7e8b5b5a451
d90eecff5c9e7e9f8263de6cd72d70322400829f

This relands below commit with asan fix:

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> inline int foo() { return 42;}
clang-repl> 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 <[email protected]>
Signed-off-by: Jun Zhang <[email protected]>

Differential Revision: https://reviews.llvm.org/D127730

show more ...

Reland "Add sanitizer metadata attributes to clang IR gen."

RE-LAND (reverts a revert):
This reverts commit 8e1f47b596b28fbc88cf32e8f46eb2fecb145fb2.

This patch adds generation of sanitizer metadat

Reland "Add sanitizer metadata attributes to clang IR gen."

RE-LAND (reverts a revert):
This reverts commit 8e1f47b596b28fbc88cf32e8f46eb2fecb145fb2.

This patch adds generation of sanitizer metadata attributes (which were
added in D126100) to the clang frontend.

We still currently generate the llvm.asan.globals that's consumed by
the IR pass, but the plan is to eventually migrate off of that onto
purely debuginfo and these IR attributes.

Reviewed By: vitalybuka, kstoimenov

Differential Revision: https://reviews.llvm.org/D126929

show more ...

Revert "Add sanitizer metadata attributes to clang IR gen."

This reverts commit e7766972a6790e25dbb4ce3481f57e9792b49269.

Broke the Windows buildbots.

Add sanitizer metadata attributes to clang IR gen.

This patch adds generation of sanitizer metadata attributes (which were
added in D126100) to the clang frontend.

We still currently generate the `

Add sanitizer metadata attributes to clang IR gen.

This patch adds generation of sanitizer metadata attributes (which were
added in D126100) to the clang frontend.

We still currently generate the `llvm.asan.globals` that's consumed by
the IR pass, but the plan is to eventually migrate off of that onto
purely debuginfo and these IR attributes.

Reviewed By: vitalybuka, kstoimenov

Differential Revision: https://reviews.llvm.org/D126929

show more ...

Reland [clang][AIX] add option mdefault-visibility-export-mapping

The option mdefault-visibility-export-mapping is created to allow
mapping default visibility to an explicit shared library export
(e

Reland [clang][AIX] add option mdefault-visibility-export-mapping

The option mdefault-visibility-export-mapping is created to allow
mapping default visibility to an explicit shared library export
(e.g. dllexport). Exactly how and if this is manifested is target
dependent (since it depends on how they map dllexport in the IR).

Three values are provided for the option:

* none: the default and behavior without the option, no additional export linkage information is created.
* explicit: add the export for entities with explict default visibility from the source, including RTTI
* all: add the export for all entities with default visibility

This option is useful for targets which do not export symbols as part of
their usual default linkage behaviour (e.g. AIX), such targets
traditionally specified such information in external files (e.g. export
lists), but this mapping allows them to use the visibility information
typically used for this purpose on other (e.g. ELF) platforms.

This relands commit: 8c8a2679a20f621994fa904bcfc68775e7345edc

with fixes for the compile time and assert problems that were reported
by:

* making shouldMapVisibilityToDLLExport inline and provide an early return
in the case where no mapping is in effect (aka non-AIX platforms)
* don't try to export RTTI types which we will give internal linkage to

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D126340

show more ...

Revert "[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder"

This reverts commit b8f9459715815fa055b3e1c5f970c616797dfcfb.

Broke the ASan buildbot. See https://reviews.llvm.org/D1267

Revert "[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder"

This reverts commit b8f9459715815fa055b3e1c5f970c616797dfcfb.

Broke the ASan buildbot. See https://reviews.llvm.org/D126781 for more
information.

show more ...

Revert "Also move WeakRefReferences in CodeGenModule::moveLazyEmssionStates"

This reverts commit 0ecbedc0986bd4b7b90a60a5f31d32337160d4c4.

Parent change broke the ASan buildbot. See
https://reviews

Revert "Also move WeakRefReferences in CodeGenModule::moveLazyEmssionStates"

This reverts commit 0ecbedc0986bd4b7b90a60a5f31d32337160d4c4.

Parent change broke the ASan buildbot. See
https://reviews.llvm.org/D126781 for more information.

show more ...

Also move WeakRefReferences in CodeGenModule::moveLazyEmssionStates

I forgot this field in b8f9459715815fa055b3e1c5f970c616797dfcfb
Signed-off-by: Jun Zhang <[email protected]>

[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder

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 s

[CodeGen] Keep track info of lazy-emitted symbols in ModuleBuilder

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> inline int foo() { return 42;}
clang-repl> 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 <[email protected]>
Signed-off-by: Jun Zhang <[email protected]>

Differential Revision: https://reviews.llvm.org/D126781

show more ...

Revert "[clang][AIX] add option mdefault-visibility-export-mapping"

This caused assertions, see comment on the code review:

llvm/clang/lib/AST/Decl.cpp:1510:
clang::LinkageInfo clang::LinkageComput

Revert "[clang][AIX] add option mdefault-visibility-export-mapping"

This caused assertions, see comment on the code review:

llvm/clang/lib/AST/Decl.cpp:1510:
clang::LinkageInfo clang::LinkageComputer::getLVForDecl(const clang::NamedDecl *, clang::LVComputationKind):
Assertion `D->getCachedLinkage() == LV.getLinkage()' failed.

> The option mdefault-visibility-export-mapping is created to allow
> mapping default visibility to an explicit shared library export
> (e.g. dllexport). Exactly how and if this is manifested is target
> dependent (since it depends on how they map dllexport in the IR).
>
> Three values are provided for the option:
>
> * none: the default and behavior without the option, no additional export linkage information is created.
> * explicit: add the export for entities with explict default visibility from the source, including RTTI
> * all: add the export for all entities with default visibility
>
> This option is useful for targets which do not export symbols as part of
> their usual default linkage behaviour (e.g. AIX), such targets
> traditionally specified such information in external files (e.g. export
> lists), but this mapping allows them to use the visibility information
> typically used for this purpose on other (e.g. ELF) platforms.
>
> Reviewed By: MaskRay
>
> Differential Revision: https://reviews.llvm.org/D126340

This reverts commit 8c8a2679a20f621994fa904bcfc68775e7345edc.

show more ...

[clang][AIX] add option mdefault-visibility-export-mapping

The option mdefault-visibility-export-mapping is created to allow
mapping default visibility to an explicit shared library export
(e.g. dll

[clang][AIX] add option mdefault-visibility-export-mapping

The option mdefault-visibility-export-mapping is created to allow
mapping default visibility to an explicit shared library export
(e.g. dllexport). Exactly how and if this is manifested is target
dependent (since it depends on how they map dllexport in the IR).

Three values are provided for the option:

* none: the default and behavior without the option, no additional export linkage information is created.
* explicit: add the export for entities with explict default visibility from the source, including RTTI
* all: add the export for all entities with default visibility

This option is useful for targets which do not export symbols as part of
their usual default linkage behaviour (e.g. AIX), such targets
traditionally specified such information in external files (e.g. export
lists), but this mapping allows them to use the visibility information
typically used for this purpose on other (e.g. ELF) platforms.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D126340

show more ...

[OpenMP] Use the align clause value from 'omp allocate' for globals

Refactor the code that handles the align clause of 'omp allocate' so
it can be used with globals as well as local variables.

Diff

[OpenMP] Use the align clause value from 'omp allocate' for globals

Refactor the code that handles the align clause of 'omp allocate' so
it can be used with globals as well as local variables.

Differential Revision: https://reviews.llvm.org/D126426

show more ...

[Cuda] Use fallback method to mangle externalized decls if no CUID given

CUDA requires that static variables be visible to the host when
offloading. However, The standard semantics of a stiatc varia

[Cuda] Use fallback method to mangle externalized decls if no CUID given

CUDA requires that static variables be visible to the host when
offloading. However, The standard semantics of a stiatc variable dictate
that it should not be visible outside of the current file. In order to
access it from the host we need to perform "externalization" on the
static variable on the device. This requires generating a semi-unique
name that can be affixed to the variable as to not cause linker errors.

This is currently done using the CUID functionality, an MD5 hash value
set up by the clang driver. This allows us to achieve is mostly unique
ID that is unique even between multiple compilations of the same file.
However, this is not always availible. Instead, this patch uses the
unique ID from the file to generate a unique symbol name. This will
create a unique name that is consistent between the host and device side
compilations without requiring the CUID to be entered by the driver. The
one downside to this is that we are no longer stable under multiple
compilations of the same file. However, this is a very niche use-case
and is not supported by Nvidia's CUDA compiler so it likely to be good
enough.

Reviewed By: tra

Differential Revision: https://reviews.llvm.org/D125904

show more ...