Overload all llvm.annotation intrinsics for globals argument

The global constant arguments could be in a different address space
than the first argument, so we have to add another overloaded argumen

Overload all llvm.annotation intrinsics for globals argument

The global constant arguments could be in a different address space
than the first argument, so we have to add another overloaded argument.
This patch was originally made for CHERI LLVM (where globals can be in
address space 200), but it also appears to be useful for in-tree targets
as can be seen from the test diffs.

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

show more ...

[CodeGen] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of

[CodeGen] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[clang-repl] Fix ambiguous initializer list.

Some platforms report that GlobalTopLevelStmtBlockInFlight cannot be initalized
with '{}' due to operator '=' being ambiguous.

This patch is a follow up

[clang-repl] Fix ambiguous initializer list.

Some platforms report that GlobalTopLevelStmtBlockInFlight cannot be initalized
with '{}' due to operator '=' being ambiguous.

This patch is a follow up to https://reviews.llvm.org/D127284 trying to appease
the bots.

show more ...

[clang-repl] Support statements on global scope in incremental mode.

This patch teaches clang to parse statements on the global scope to allow:
```
./bin/clang-repl
clang-repl> int i = 12;
clang-rep

[clang-repl] Support statements on global scope in incremental mode.

This patch teaches clang to parse statements on the global scope to allow:
```
./bin/clang-repl
clang-repl> int i = 12;
clang-repl> ++i;
clang-repl> extern "C" int printf(const char*,...);
clang-repl> printf("%d\n", i);
13
clang-repl> %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

show more ...

[clang] Avoid duplicating ProgramAddressSpace in TargetInfo. NFCI

This value was added to clang/Basic in D111566, but is only used during
codegen, where we can use the LLVM IR DataLayout instead. I

[clang] Avoid duplicating ProgramAddressSpace in TargetInfo. NFCI

This value was added to clang/Basic in D111566, but is only used during
codegen, where we can use the LLVM IR DataLayout instead. I noticed this
because the downstream CHERI targets would have to also set this value
for AArch64/RISC-V/MIPS. Instead of duplicating more information between
LLVM IR and Clang, this patch moves getTargetAddressSpace(QualType T) to
CodeGenTypes, where we can consult the DataLayout.

Reviewed By: rjmccall

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

show more ...

[clang][TargetInfo] Use LangAS for getPointer{Width,Align}()

Mixing LLVM and Clang address spaces can result in subtle bugs, and there
is no need for this hook to use the LLVM IR level address space

[clang][TargetInfo] Use LangAS for getPointer{Width,Align}()

Mixing LLVM and Clang address spaces can result in subtle bugs, and there
is no need for this hook to use the LLVM IR level address spaces.
Most of this change is just replacing zero with LangAS::Default,
but it also allows us to remove a few calls to getTargetAddressSpace().

This also removes a stale comment+workaround in
CGDebugInfo::CreatePointerLikeType(): ASTContext::getTypeSize() does
return the expected size for ReferenceType (and handles address spaces).

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

show more ...

[AVR] Fix broken bitcast for aliases in non-zero address space

This was triggered by some code in picolibc. The minimal version looks
like this:

double infinity(void) {
return 5;
}

[AVR] Fix broken bitcast for aliases in non-zero address space

This was triggered by some code in picolibc. The minimal version looks
like this:

double infinity(void) {
return 5;
}

extern long double infinityl() __attribute__((__alias__("infinity")));

These two declarations have a different type (not because of the 'long
double', which is also 'double' in IR, but because infinityl has
variadic parameters). This led to a crash in the bitcast which assumed
address space 0.

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

show more ...

Fix declare target implementation to support enter.

[HLSL] CodeGen hlsl cbuffer/tbuffer.

cbuffer A {
float a;
float b;
}

will be translated to a global variable.

Something like

struct CB_Ty {
float a;
float b;
};

CB_Ty A;

And all use of

[HLSL] CodeGen hlsl cbuffer/tbuffer.

cbuffer A {
float a;
float b;
}

will be translated to a global variable.

Something like

struct CB_Ty {
float a;
float b;
};

CB_Ty A;

And all use of a and b will be replaced with A.a and A.b.

Only support none-legacy cbuffer layout now.
CodeGen for Resource binding will be in separate patch.
In the separate patch, resource binding will map the resource information to the global variable.

Reviewed By: efriedma

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

show more ...

[Clang][AArch64] Support AArch64 target(..) attribute formats.

This adds support under AArch64 for the target("..") attributes. The
current parsing is very X86-shaped, this patch attempts to bring i

[Clang][AArch64] Support AArch64 target(..) attribute formats.

This adds support under AArch64 for the target("..") attributes. The
current parsing is very X86-shaped, this patch attempts to bring it line
with the GCC implementation from
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes.

The supported formats are:
- "arch=<arch>" strings, that specify the architecture features for a
function as per the -march=arch+feature option.
- "cpu=<cpu>" strings, that specify the target-cpu and any implied
atributes as per the -mcpu=cpu+feature option.
- "tune=<cpu>" strings, that specify the tune-cpu cpu for a function as
per -mtune.
- "+<feature>", "+no<feature>" enables/disables the specific feature, for
compatibility with GCC target attributes.
- "<feature>", "no-<feature>" enabled/disables the specific feature, for
backward compatibility with previous releases.

To do this, the parsing of target attributes has been moved into
TargetInfo to give the target the opportunity to override the existing
parsing. The only non-aarch64 change should be a minor alteration to the
error message, specifying using "CPU" to describe the cpu, not
"architecture", and the DuplicateArch/Tune from ParsedTargetAttr have
been combined into a single option.

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

show more ...

[IR] Don't allow DLL storage-class and local linkage

Disallow this meaningless combination. Doing so simplifies analysis
of LLVM code w.r.t t DLL storage-class, and prevents mistakes with
DLL storag

[IR] Don't allow DLL storage-class and local linkage

Disallow this meaningless combination. Doing so simplifies analysis
of LLVM code w.r.t t DLL storage-class, and prevents mistakes with
DLL storage class.

- Change the assembler to reject DLL storage class on symbols with
local linkage.
- Change the bitcode reader to clear the DLL Storage class when the
linkage is local for auto-upgrading
- Update LangRef.

There is an existing restriction on non-default visibility and local
linkage which this is modelled on.

Differential Review: https://reviews.llvm.org/D134784

show more ...

[AMDGPU] Emit module flag for all code object versions

Reviewed by: Changpeng Fang, Matt Arsenault, Brian Sumner

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

[Clang] Give error message for invalid profile path when compiling IR

Before this patch, when compiling an IR file (eg the .llvmbc section
from an object file compiled with -Xclang -fembed-bitcode=a

[Clang] Give error message for invalid profile path when compiling IR

Before this patch, when compiling an IR file (eg the .llvmbc section
from an object file compiled with -Xclang -fembed-bitcode=all) and
profile data was passed in using the -fprofile-instrument-use-path
flag, there would be no error printed (as the previous implementation
relied on the error getting caught again in the constructor of
CodeGenModule which isn't called when -x ir is set). This patch
moves the error checking directly to where the error is caught
originally rather than failing silently in setPGOUseInstrumentor and
waiting to catch it in CodeGenModule to print diagnostic information to
the user.

Regression test added.

Reviewed By: xur, mtrofin

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

show more ...

Revert "Revert "[clang, llvm] Add __declspec(safebuffers), support it in CodeView""

This reverts commit cd20a1828605887699579789b5433111d5bc0319 and adds a
"let Heading" to NoStackProtectorDocs.

Revert "[clang, llvm] Add __declspec(safebuffers), support it in CodeView"

Causing:
https://github.com/llvm/llvm-project/issues/57709

This reverts commit ab56719acd98778fb2e48fa425ac7c8d27bdea86.

[MinGW] Reject explicit hidden visibility applied to dllexport and hidden/protected applied to dllimport

Hidden visibility is incompatible with dllexport.
Hidden and protected visibilities are incom

[MinGW] Reject explicit hidden visibility applied to dllexport and hidden/protected applied to dllimport

Hidden visibility is incompatible with dllexport.
Hidden and protected visibilities are incompatible with dllimport.
(PlayStation uses dllexport protected.)

When an explicit visibility attribute applies on a dllexport/dllimport
declaration, report a Frontend error (Sema does not compute visibility).

Reviewed By: mstorsjo

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

show more ...

[clang, llvm] Add __declspec(safebuffers), support it in CodeView

__declspec(safebuffers) is equivalent to
__attribute__((no_stack_protector)). This information is recorded in
CodeView.

While we a

[clang, llvm] Add __declspec(safebuffers), support it in CodeView

__declspec(safebuffers) is equivalent to
__attribute__((no_stack_protector)). This information is recorded in
CodeView.

While we are here, add support for strict_gs_check.

show more ...

Revert D133266 "[MinGW] Reject explicit non-default visibility applied to dllexport/dllimport declaration"

This reverts commit 91d8324366f405e871aa8174ab61fc66912964dd.

The combo dllexport protecte

Revert D133266 "[MinGW] Reject explicit non-default visibility applied to dllexport/dllimport declaration"

This reverts commit 91d8324366f405e871aa8174ab61fc66912964dd.

The combo dllexport protected makes sense and is used by PlayStation.
Will change the patch to allow dllexport protected.

show more ...

[MinGW] Reject explicit non-default visibility applied to dllexport/dllimport declaration

dllimport/dllexport is incompatible with protected/hidden visibilities.
(Arguably dllexport semantics is com

[MinGW] Reject explicit non-default visibility applied to dllexport/dllimport declaration

dllimport/dllexport is incompatible with protected/hidden visibilities.
(Arguably dllexport semantics is compatible with protected but let's reject the
combo for simplicity.)

When an explicit visibility attribute applies on a dllexport/dllimport
declaration, report a Frontend error (Sema does not compute visibility).

Reviewed By: mstorsjo

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

show more ...

[MinGW] Ignore -fvisibility/-fvisibility-inlines-hidden for dllexport

Similar to 123ce97fac78bc4519afd5d2aba17c59c5717aad for dllimport: dllexport
expresses a non-hidden visibility intention. We can

[MinGW] Ignore -fvisibility/-fvisibility-inlines-hidden for dllexport

Similar to 123ce97fac78bc4519afd5d2aba17c59c5717aad for dllimport: dllexport
expresses a non-hidden visibility intention. We can consider it explicit and
therefore it should override the global visibility setting (see AST/Decl.cpp
"NamedDecl Implementation").

Adding the special case to CodeGenModule::setGlobalVisibility is somewhat weird,
but allows we to add the code in one place instead of many in AST/Decl.cpp.

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

show more ...

[llvm-profdata] Handle internal linkage functions in profile supplementation

This patch has the following changes:
(1) Handling of internal linkage functions (static functions)
Static functions in F

[llvm-profdata] Handle internal linkage functions in profile supplementation

This patch has the following changes:
(1) Handling of internal linkage functions (static functions)
Static functions in FDO have a prefix of source file name, while they do not
have one in SampleFDO. Current implementation does not handle this and we are
not updating the profile for static functions. This patch fixes this.

(2) Handling of -funique-internal-linakge-symbols
Again this is for the internal linkage functions. Option
-funique-internal-linakge-symbols can now be applied to both FDO and SampleFDO
compilation. When it is used, it demangles internal linkage function names and
adds a hash value as the postfix.

When both SampleFDO and FDO profiles use this option, or both
not use this option, changes in (1) should handle this.

Here we also handle when the SampleFDO profile using this option while FDO
profile not using this option, or vice versa.

There is one case where this patch won't work: If one of the profiles used
mangled name and the other does not. For example, if the SampleFDO profile
uses clang c-compiler and without -funique-internal-linakge-symbols, while
the FDO profile uses -funique-internal-linakge-symbols. The SampleFDO profile
contains unmangled names while the FDO profile contains mangled names. If
both profiles use c++ compiler, this won't happen. We think this use case
is rare and does not justify the effort to fix.

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

show more ...

[Clang] Implement function attribute nouwtable

To have finer control of IR uwtable attribute generation. For target code generation,
IR nounwind and uwtable may have some interaction. However, for f

[Clang] Implement function attribute nouwtable

To have finer control of IR uwtable attribute generation. For target code generation,
IR nounwind and uwtable may have some interaction. However, for frontend, there are
no semantic interactions so the this new `nouwtable` is marked "SimpleHandler = 1".

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

show more ...

[CodeGen] Track DeferredDecls that have been emitted

If we run into a first usage or definition of a mangled name, and
there's a DeferredDecl that associated with it, we should remember it we
need t

[CodeGen] Track DeferredDecls that have been emitted

If we run into a first usage or definition of a mangled name, and
there's a DeferredDecl that associated with it, we should remember it we
need to emit it later on.

Without this patch, clang-repl hits a JIT symbol not found error:
clang-repl> extern "C" int printf(const char *, ...);
clang-repl> auto l1 = []() { printf("ONE\n"); return 42; };
clang-repl> auto l2 = []() { printf("TWO\n"); return 17; };
clang-repl> auto r1 = l1();
ONE
clang-repl> auto r2 = l2();
TWO
clang-repl> auto r3 = l2();
JIT session error: Symbols not found: [ l2 ]
error: Failed to materialize symbols: { (main,
{ r3, orc_init_func.incr_module_5, $.incr_module_5.inits.0 }) }

Signed-off-by: Jun Zhang <jun@junz.org>

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

show more ...

[HLSL] Initial codegen for SV_GroupIndex

Semantic parameters aren't passed as actual parameters, instead they are
populated from intrinsics which are generally lowered to reads from
dedicated hardwa

[HLSL] Initial codegen for SV_GroupIndex

Semantic parameters aren't passed as actual parameters, instead they are
populated from intrinsics which are generally lowered to reads from
dedicated hardware registers.

This change modifies clang CodeGen to emit the intrinsic calls and
populate the parameter's LValue with the result of the intrinsic call
for SV_GroupIndex.

The result of this is to make the actual passed argument ignored, which
will make it easy to clean up later in an IR pass.

Reviewed By: aaron.ballman

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

show more ...

[clang-cl] /kernel should toggle bit 30 in @feat.00

The linker is supposed to detect when an object with /kernel is linked
with another object which is not compiled with /kernel. The linker
detects

[clang-cl] /kernel should toggle bit 30 in @feat.00

The linker is supposed to detect when an object with /kernel is linked
with another object which is not compiled with /kernel. The linker
detects this by checking bit 30 in @feat.00.

show more ...