[NFC] [C++20] [Modules] Refactor Module::getGlobalModuleFragment and Module::getPrivateModuleFragment

The original implementation of `Module::getGlobalModuleFragment` and
`Module::getPrivateModuleFr

[NFC] [C++20] [Modules] Refactor Module::getGlobalModuleFragment and Module::getPrivateModuleFragment

The original implementation of `Module::getGlobalModuleFragment` and
`Module::getPrivateModuleFragment` tried to find the global module
fragment and the private module fragment by comparing strings, which
smells bad. This patch tries to improve this.

show more ...

[clang] Add -mlarge-data-threshold for x86_64 medium code model (#66839)

Error if not used with x86_64.
Warn if not used with the medium code model (can update if other code
models end up using th

[clang] Add -mlarge-data-threshold for x86_64 medium code model (#66839)

Error if not used with x86_64.
Warn if not used with the medium code model (can update if other code
models end up using this).

Set TargetMachine option and add module flag.

show more ...

[clang][CodeGen] Simplify code based on opaque pointers (#65624)

- Update CodeGenTypeCache to use a single union for all pointers in
address space zero.
- Introduce a UnqualPtrTy in CodeGenTypeCac

[clang][CodeGen] Simplify code based on opaque pointers (#65624)

- Update CodeGenTypeCache to use a single union for all pointers in
address space zero.
- Introduce a UnqualPtrTy in CodeGenTypeCache, and use that (for
example instead of llvm::PointerType::getUnqual) in some places.
- Drop some redundant bit/pointers casts from ptr to ptr.

show more ...

Revert "[clang][CodeGen] Emit annotations for function declarations."

This reverts commit c6a33ff49dfb3498dae15c718820ea3d9c19f3cb. Makes
clang segfault.

// clang t.cc
class a;
class c {
public:

Revert "[clang][CodeGen] Emit annotations for function declarations."

This reverts commit c6a33ff49dfb3498dae15c718820ea3d9c19f3cb. Makes
clang segfault.

// clang t.cc
class a;
class c {
public:
[[clang::annotate("")]] c(const c *) {}
};
class d {
d(const c *, a *, a *);
c e;
};
d::d(const c *f, a *, a *) : e(f) {}

show more ...

[clang][CodeGen] Emit annotations for function declarations.

Previously, annotations were only emitted for function definitions. With
this change annotations are also emitted for declarations. Also,

[clang][CodeGen] Emit annotations for function declarations.

Previously, annotations were only emitted for function definitions. With
this change annotations are also emitted for declarations. Also, emitting
function annotations is now deferred until the end so that the most
up to date declaration is used which will have any inherited annotations.

Differential Revision: https://reviews.llvm.org/D156172/new/

show more ...

Reapply "[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`"

This reapplies ddbcc10b9e26b18f6a70e23d0611b9da75ffa52f, except for a tiny part that was reverted separately: 65331da0032ab4253a

Reapply "[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`"

This reapplies ddbcc10b9e26b18f6a70e23d0611b9da75ffa52f, except for a tiny part that was reverted separately: 65331da0032ab4253a4bc0ddcb2da67664bd86a9. That will be reapplied later on, since it turned out to be more involved.

This commit is enabled by 5523fefb01c282c4cbcaf6314a9aaf658c6c145f and f0f548a65a215c450d956dbcedb03656449705b9, specifically the part that makes 'clang-tidy/checkers/misc/header-include-cycle.cpp' separator agnostic.

show more ...

Revert "[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`"

This reverts commit ddbcc10b9e26b18f6a70e23d0611b9da75ffa52f.

The 'clang-tidy/checkers/misc/header-include-cycle.cpp' test start

Revert "[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`"

This reverts commit ddbcc10b9e26b18f6a70e23d0611b9da75ffa52f.

The 'clang-tidy/checkers/misc/header-include-cycle.cpp' test started failing on Windows: https://lab.llvm.org/buildbot/#/builders/216/builds/26855.

show more ...

[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`

This commit replaces some calls to the deprecated `FileEntry::getName()` with `FileEntryRef::getName()` by swapping current usages of `Sou

[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`

This commit replaces some calls to the deprecated `FileEntry::getName()` with `FileEntryRef::getName()` by swapping current usages of `SourceManager::getFileEntryForID()` with `SourceManager::getFileEntryRefForID()`. This lowers the number of usages of the deprecated `FileEntry::getName()` from 95 to 50.

show more ...

[CodeGen] First check the kind and then the llvm::Function properties.

This patch fixes valgrind reports from downstream consumers about conditional
jump over uninitialised memory.

The original rep

[CodeGen] First check the kind and then the llvm::Function properties.

This patch fixes valgrind reports from downstream consumers about conditional
jump over uninitialised memory.

The original report:

```[ RUN ] ScopeReflectionTest.IsComplete
==987150== Conditional jump or move depends on uninitialised value(s)
==987150== at 0x1E1128F: clang::CodeGen::CodeGenModule::SetLLVMFunctionAttributesForDefinition(clang::Decl const*, llvm::Function*) (CodeGenModule.cpp:2391)
==987150== by 0x1E4F181: clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:5669)
==987150== by 0x1E4A194: clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:3909)
==987150== by 0x1E4A752: clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (CodeGenModule.cpp:3649)
==987150== by 0x1E532F5: clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) [clone .part.0] (CodeGenModule.cpp:6563)
==987150== by 0x1B0BEDD: (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) (ModuleBuilder.cpp:190)
==987150== by 0x1AEA47B: clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (CodeGenAction.cpp:235)
==987150== by 0x101B02F: clang::IncrementalASTConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (IncrementalParser.cpp:52)
==987150== by 0x101ED93: clang::IncrementalParser::ParseOrWrapTopLevelDecl() (IncrementalParser.cpp:276)
==987150== by 0x101FBBC: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:342)
==987150== by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360)
==987150== by 0xE734C0: Cpp::Interpreter::Parse(llvm::StringRef) (CppInterOpInterpreter.h:172)
==987150== Uninitialised value was created by a heap allocation
==987150== at 0x844BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==987150== by 0x1B0C882: StartModule (ModuleBuilder.cpp:139)
==987150== by 0x1B0C882: clang::CodeGenerator::StartModule(llvm::StringRef, llvm::LLVMContext&) (ModuleBuilder.cpp:360)
==987150== by 0x101C4AF: clang::IncrementalParser::GenModule() (IncrementalParser.cpp:372)
==987150== by 0x101FC0E: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:362)
==987150== by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360)
==987150== by 0x100E243: clang::Interpreter::create(std::unique_ptr<clang::CompilerInstance, std::default_delete<clang::CompilerInstance> >) (Interpreter.cpp:279)
==987150== by 0xF2131A: compat::createClangInterpreter(std::vector<char const*, std::allocator<char const*> >&) (Compatibility.h:123)
==987150== by 0xF22AB9: Cpp::Interpreter::Interpreter(int, char const* const*, char const*, std::vector<std::shared_ptr<clang::ModuleFileExtension>, std::allocator<std::shared_ptr<clang::ModuleFileExtension> > > const&, void*, bool) (CppInterOpInterpreter.h:146)
==987150== by 0xF1827A: CreateInterpreter (CppInterOp.cpp:2494)
==987150== by 0xECFA0E: TestUtils::GetAllTopLevelDecls(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<clang::Decl*, std::allocator<clang::Decl*> >&, bool) (Utils.cpp:23)
==987150== by 0xE9CB85: ScopeReflectionTest_IsComplete_Test::TestBody() (ScopeReflectionTest.cpp:71)
==987150== by 0xF0ED0C: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (in /home/vvassilev/workspace/builds/scratch/cppyy/InterOp/build-with-clang-repl-release/unittests/CppInterOp/CppInterOpTests)
==987150==
```

Differential revision: https://reviews.llvm.org/D159339

show more ...

[clang] [MinGW] Add the option -fno-auto-import

In GCC, the .refptr stubs are only generated for x86_64, and only
for code models medium and larger (and medium is the default for
x86_64 since this w

[clang] [MinGW] Add the option -fno-auto-import

In GCC, the .refptr stubs are only generated for x86_64, and only
for code models medium and larger (and medium is the default for
x86_64 since this was introduced). They can be omitted for
projects that are conscious about performance and size, and don't
need automatically importing dll data members, by passing -mcmodel=small.

In Clang/LLVM, such .refptr stubs are generated for any potentially
symbol reference that might end up autoimported. The .refptr stubs
are emitted for three separate reasons:
- Without .refptr stubs, undefined symbols are mostly referenced
with 32 bit wide relocations. If the symbol ends up autoimported
from a different DLL, a 32 bit relative offset might not be
enough to reference data in a different DLL, depending on runtime
loader layout.
- Without .refptr stubs, the runtime pseudo relocation mechanism
will need to temporarily make sections read-write-executable
if there are such relocations in the text section
- On ARM and AArch64, the immediate addressing encoded into
instructions isn't in the form of a plain 32 bit relative offset,
but is expressed with various bits scattered throughout two
instructions - the mingw runtime pseudo relocation mechanism
doesn't support updating offsets in that form.

If autoimporting is known not to be needed, the user can now
compile with -fno-auto-import, avoiding the extra overhead of
the .refptr stubs.

However, omitting them is potentially fragile as the code
might still rely on automatically importing some symbol without
the developer knowing. If this happens, linking still usually
will succeed, but users may encounter issues at runtime.

Therefore, if the new option -fno-auto-import is passed to the compiler
when driving linking, it passes the flag --disable-auto-import to
the linker, making sure that no symbols actually are autoimported
when the generated code doesn't expect it.

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

show more ...

[XCOFF][AIX] Issue an error when specifying an alias for a common symbol

Summary:

There is no support in XCOFF for labels on common symbols. Therefore, an alias for a common symbol is not supported

[XCOFF][AIX] Issue an error when specifying an alias for a common symbol

Summary:

There is no support in XCOFF for labels on common symbols. Therefore, an alias for a common symbol is not supported. Issue an error in the front end when an aliasee is a common symbol. Issue a similar error in the back end in case an IR specifies an alias for a common symbol.

Reviewed by: hubert.reinterpretcast, DiggerLin

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

show more ...

[CodeGen] Function multi-versioning: don't set comdat for internal linkage resolvers

For function multi-versioning using the target or target_clones
function attributes, currently we incorrectly set

[CodeGen] Function multi-versioning: don't set comdat for internal linkage resolvers

For function multi-versioning using the target or target_clones
function attributes, currently we incorrectly set comdat for internal
linkage resolvers. This is problematic for ELF linkers
as GRP_COMDAT deduplication will kick in even with STB_LOCAL signature
(https://groups.google.com/g/generic-abi/c/2X6mR-s2zoc
"GRP_COMDAT group with STB_LOCAL signature").

In short, two `__attribute((target_clones(...))) static void foo()`
in two translation units will be deduplicated. Fix this.

Fix #65114

Reviewed By: erichkeane

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

show more ...

[NFC] Remove unused variables declared in conditions

D152495 makes clang warn on unused variables that are declared in conditions like `if (int var = init) {}`
This patch is an NFC fix to suppress t

[NFC] Remove unused variables declared in conditions

D152495 makes clang warn on unused variables that are declared in conditions like `if (int var = init) {}`
This patch is an NFC fix to suppress the new warning in llvm,clang,lld builds to pass CI in the above patch.

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

show more ...

[OpenMP][DeviceRTL][AMDGPU] Support code object version 5

Update DeviceRTL and the AMDGPU plugin to support code
object version 5. Default is code object version 4.

CodeGen for __builtin_amdgpu_wor

[OpenMP][DeviceRTL][AMDGPU] Support code object version 5

Update DeviceRTL and the AMDGPU plugin to support code
object version 5. Default is code object version 4.

CodeGen for __builtin_amdgpu_workgroup_size generates code
for cov4 as well as cov5 if -mcode-object-version=none
is specified. DeviceRTL compilation passes this argument
via Xclang option to generate abi-agnostic code.

Generated code for the above builtin uses a clang
control constant "llvm.amdgcn.abi.version" to branch on
the abi version, which is available during linking of
user's OpenMP code. Load of this constant gets eliminated
during linking.

AMDGPU plugin queries the ELF for code object version
and then prepares various implicitargs accordingly.

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

Reviewed By: jhuber6, yaxunl

show more ...

[MSABI] Remove comdat attribute for inheriting ctor.

Currently, for MS, the linkage for the inheriting constructors is set to
internal. However, the comdat attribute is also set like:

define inter

[MSABI] Remove comdat attribute for inheriting ctor.

Currently, for MS, the linkage for the inheriting constructors is set to
internal. However, the comdat attribute is also set like:

define internal noundef ptr @"??0?$B@_N@@qeaa@AEBVF@@aebua@@@z"(ptr noundef nonnull returned align 1 dereferenceable(1) %this, ptr noundef nonnull align 1 dereferenceable(1) %0, ptr noundef nonnull align 1 dereferenceable(1) %1) unnamed_addr comdat

This could cause linker to fail.

The change is to remove comdat attribute for the inheriting constructor
to make linker happy.

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

show more ...

[X86] __builtin_cpu_supports: support x86-64{,-v2,-v3,-v4}

GCC 12 (https://gcc.gnu.org/PR101696) allows
__builtin_cpu_supports("x86-64") (and -v2 -v3 -v4).
This patch ports the feature.

* Add `FEAT

[X86] __builtin_cpu_supports: support x86-64{,-v2,-v3,-v4}

GCC 12 (https://gcc.gnu.org/PR101696) allows
__builtin_cpu_supports("x86-64") (and -v2 -v3 -v4).
This patch ports the feature.

* Add `FEATURE_X86_64_{BASELINE,V2,V3,V4}` to enum ProcessorFeatures,
but keep CPU_FEATURE_MAX unchanged to make
FeatureInfos/FeatureInfos_WithPLUS happy.
* Change validateCpuSupports to allow `x86-64{,-v2,-v3,-v4}`
* Change getCpuSupportsMask to return `std::array<uint32_t, 4>` where
`x86-64{,-v2,-v3,-v4}` set bits `FEATURE_X86_64_{BASELINE,V2,V3,V4}`.
* `target("x86-64")` and `cpu_dispatch(x86_64)` are invalid. Tested by commit 9de3b35ac9159d5bae6e6796cb91e4f877a07189

Close https://github.com/llvm/llvm-project/issues/59961

Reviewed By: pengfei

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

show more ...

[OpenMP] Emit offloading entries for indirect target variables

OpenMP 5.1 allows emission of the `indirect` clause on declare target
functions, see https://www.openmp.org/spec-html/5.1/openmpsu70.ht

[OpenMP] Emit offloading entries for indirect target variables

OpenMP 5.1 allows emission of the `indirect` clause on declare target
functions, see https://www.openmp.org/spec-html/5.1/openmpsu70.html#x98-1080002.14.7.
The intended use of this is to permit calling device functions via their
associated host pointer. In order to do this the first step will be
building a map associating these variables. Doing this will require the
same offloading entry handling we use for other kernels and globals.

We intentionally emit a new global on the device side. Although it's
possible to look up the device function's address directly, this would
require changing the visibility and would prevent us from making static
functions indirect. Also, the CUDA toolchain will optimize out unused
functions and using a global prevents that. The downside is that the
runtime will need to read the global and copy its value, but there
shouldn't be any other costs.

Note that this patch just performs the codegen, currently this new
offloading entry type is unused and will be ignored by the runtime.

Reviewed By: jdoerfert

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

show more ...

[CodeGen] Keep track of eagerly emitted globals

An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizatio

[CodeGen] Keep track of eagerly emitted globals

An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizations stripped it from the Module. The added test case
shows the problem; before this patch, it would fail with:
Symbols not found: [ _ZN1AD0Ev, _ZN1AD1Ev ]

This reapplies commit f8dadefd4a, reverted in commit 0e17372b38, but
disables RTTI in the test to avoid problems on Windows.

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

show more ...

Revert "[CodeGen] Keep track of eagerly emitted globals"

The added test doesn't work on Windows:
https://lab.llvm.org/buildbot/#/builders/216/builds/25769

This reverts commit f8dadefd4afc8e1b7b9a1e

Revert "[CodeGen] Keep track of eagerly emitted globals"

The added test doesn't work on Windows:
https://lab.llvm.org/buildbot/#/builders/216/builds/25769

This reverts commit f8dadefd4afc8e1b7b9a1e69a0ba8df051e03328.

show more ...

[CodeGen] Keep track of eagerly emitted globals

An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizatio

[CodeGen] Keep track of eagerly emitted globals

An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizations stripped it from the Module. The added test case
shows the problem; before this patch, it would fail with:
Symbols not found: [ _ZN1AD0Ev, _ZN1AD1Ev ]

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

show more ...

[CodeGen] Clean up access to EmittedDeferredDecls, NFCI.

GlobalDecls should only be added to EmittedDeferredDecls if they
need reemission. This is checked in addEmittedDeferredDecl, which
is called

[CodeGen] Clean up access to EmittedDeferredDecls, NFCI.

GlobalDecls should only be added to EmittedDeferredDecls if they
need reemission. This is checked in addEmittedDeferredDecl, which
is called via addDeferredDeclToEmit. Extend these checks to also
handle VarDecls (for lambdas, as tested in Interpreter/lambda.cpp)
and remove the direct access of EmittedDeferredDecls in EmitGlobal
that may actually end up duplicating FunctionDecls.

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

show more ...

[CodeGen] Remove Constant arguments from linkage functions, NFCI.

This was unused since commit dd2362a8ba last year.

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

Make globals with mutable members non-constant, even in custom sections

Turned out we were making overly simple assumptions about which sections (& section flags) would be used when emitting a globa

Make globals with mutable members non-constant, even in custom sections

Turned out we were making overly simple assumptions about which sections (& section flags) would be used when emitting a global into a custom section. This lead to sections with read-only flags being used for globals of struct types with mutable members.

Fixed by porting the codegen function with the more nuanced handling/checking for mutable members out of codegen for use in the sema code that does this initial checking/mapping to section flags.

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

show more ...

Disable sanitizer's on ifunc resolvers.

Resolvers are running before the module is initialised which leads to
crashes due to the santizer is not yet initialised.

Fixes #40287

Reviewed By: hctim

D

Disable sanitizer's on ifunc resolvers.

Resolvers are running before the module is initialised which leads to
crashes due to the santizer is not yet initialised.

Fixes #40287

Reviewed By: hctim

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

show more ...

[clang] Drop some references to typed pointers (getInt8PtrTy). NFC

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