[Clang] Allow bitcode linking when the input is LLVM-IR

Clang provides the `-mlink-bitcode-file` and `-mlink-builtin-bitcode`
options to insert LLVM-IR into the current TU. These are usefuly
primari

[Clang] Allow bitcode linking when the input is LLVM-IR

Clang provides the `-mlink-bitcode-file` and `-mlink-builtin-bitcode`
options to insert LLVM-IR into the current TU. These are usefuly
primarily for including LLVM-IR files that require special handling to
be correct and cannot be linked normally, such as GPU vendor libraries
like `libdevice.10.bc`. Currently these options can only be used if the
source input goes through the AST consumer path. This patch makes the
changes necessary to also support this when the input is LLVM-IR. This
will allow the following operation:

```
clang in.bc -Xclang -mlink-builtin-bitcode -Xclang libdevice.10.bc
```

Reviewed By: yaxunl

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

show more ...

[Clang] Remove -no-opaque-pointers cc1 flag

Migration of clang tests to opaque pointers is finished, so remove
the -no-opaque-pointers flag.

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

reland: [Demangle] make llvm::demangle take std::string_view rather than const std::string&

As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549

There's potential for a lo

reland: [Demangle] make llvm::demangle take std::string_view rather than const std::string&

As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549

There's potential for a lot more cleanups around these APIs. This is
just a start.

Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using `llvm::demangle`. Add a
release note.

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

show more ...

[clang-repl][CUDA] Re-land: Initial interactive CUDA support for clang-repl

CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used

[clang-repl][CUDA] Re-land: Initial interactive CUDA support for clang-repl

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

show more ...

Revert "[clang-repl][CUDA] Initial interactive CUDA support for clang-repl"

This reverts commit 80e7eed6a610ab3c7289e6f9b7ec006bc7d7ae31.

[clang-repl][CUDA] Initial interactive CUDA support for clang-repl

CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all

[clang-repl][CUDA] Initial interactive CUDA support for clang-repl

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

show more ...

Revert "[Demangle] make llvm::demangle take std::string_view rather than const std::string&"

This reverts commit c117c2c8ba4afd45a006043ec6dd858652b2ffcc.

itaniumDemangle calls std::strlen with the

Revert "[Demangle] make llvm::demangle take std::string_view rather than const std::string&"

This reverts commit c117c2c8ba4afd45a006043ec6dd858652b2ffcc.

itaniumDemangle calls std::strlen with the results of
std::string_view::data() which may not be NUL-terminated. This causes
lld/test/wasm/why-extract.s to fail when "expensive checks" are enabled
via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON. See D149675 for further
discussion. Back this out until the individual demanglers are converted
to use std::string_view.

show more ...

[Demangle] make llvm::demangle take std::string_view rather than const std::string&

As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549

There's potential for a lot more c

[Demangle] make llvm::demangle take std::string_view rather than const std::string&

As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549

There's potential for a lot more cleanups around these APIs. This is
just a start.

Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using ``llvm::demangle``. Add a
release note.

Reviewed By: MaskRay, #lld-macho

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

show more ...

LangRef: Add "dynamic" option to "denormal-fp-math"

This is stricter than the default "ieee", and should probably be the
default. This patch leaves the default alone. I can change this in a
future p

LangRef: Add "dynamic" option to "denormal-fp-math"

This is stricter than the default "ieee", and should probably be the
default. This patch leaves the default alone. I can change this in a
future patch.

There are non-reversible transforms I would like to perform which are
legal under IEEE denormal handling, but illegal with flushing zero
behavior. Namely, conversions between llvm.is.fpclass and fcmp with
zeroes.

Under "ieee" handling, it is legal to translate between
llvm.is.fpclass(x, fcZero) and fcmp x, 0.

Under "preserve-sign" handling, it is legal to translate between
llvm.is.fpclass(x, fcSubnormal|fcZero) and fcmp x, 0.

I would like to compile and distribute some math library functions in
a mode where it's callable from code with and without denormals
enabled, which requires not changing the compares with denormals or
zeroes.

If an IEEE function transforms an llvm.is.fpclass call into an fcmp 0,
it is no longer possible to call the function from code with denormals
enabled, or write an optimization to move the function into a denormal
flushing mode. For the original function, if x was a denormal, the
class would evaluate to false. If the function compiled with denormal
handling was converted to or called from a preserve-sign function, the
fcmp now evaluates to true.

This could also be of use for strictfp handling, where code may be
changing the denormal mode.

Alternative name could be "unknown".

Replaces the old AMDGPU custom inlining logic with more conservative
logic which tries to permit inlining for callees with dynamic handling
and avoids inlining other mismatched modes.

show more ...

[NFC][clang] Fix static analyzer tool remarks about large copies by values

Reported by Coverity:

Big parameter passed by value
Copying large values is inefficient, consider

[NFC][clang] Fix static analyzer tool remarks about large copies by values

Reported by Coverity:

Big parameter passed by value
Copying large values is inefficient, consider passing by reference; Low, medium, and high size thresholds for detection can be adjusted.

1. Inside "SemaConcept.cpp" file, in subsumes<clang::Sema::MaybeEmitAmbiguousAtomicConstraintsDiagnostic(clang::NamedDecl *, llvm::ArrayRef<clang::Expr const *>, clang::NamedDecl *, llvm::ArrayRef<clang::Expr const *>)::[lambda(clang::AtomicConstraint const &, clang::AtomicConstraint const &) (instance 2)]>(llvm::SmallVector<llvm::SmallVector<clang::AtomicConstraint *, 2u>, 4u>, llvm::SmallVector<llvm::SmallVector<clang::AtomicConstraint *, 2u>, 4u>, T1): A large function call parameter exceeding the low threshold is passed by value.

i. pass_by_value: Passing parameter PDNF of type NormalForm (size 144 bytes) by value, which exceeds the low threshold of 128 bytes.

ii. pass_by_value: Passing parameter QCNF of type NormalForm (size 144 bytes) by value, which exceeds the low threshold of 128 bytes.

2. Inside "CodeGenAction.cpp" file, in clang::reportOptRecordError(llvm::Error, clang::DiagnosticsEngine &, clang::CodeGenOptions): A very large function call parameter exceeding the high threshold is passed by value.

i. pass_by_value: Passing parameter CodeGenOpts of type clang::CodeGenOptions const (size 1560 bytes) by value, which exceeds the high threshold of 512 bytes.

3. Inside "SemaCodeComplete.cpp" file, in HandleCodeCompleteResults(clang::Sema *, clang::CodeCompleteConsumer *, clang::CodeCompletionContext, clang::CodeCompletionResult *, unsigned int): A large function call parameter exceeding the low threshold is passed by value.

i. pass_by_value: Passing parameter Context of type clang::CodeCompletionContext (size 200 bytes) by value, which exceeds the low threshold of 128 bytes.

4. Inside "SemaConcept.cpp" file, in <unnamed>::SatisfactionStackRAII::SatisfactionStackRAII(clang::Sema &, clang::NamedDecl const *, llvm::FoldingSetNodeID): A large function call parameter exceeding the low threshold is passed by value.

i. pass_by_value: Passing parameter FSNID of type llvm::FoldingSetNodeID (size 144 bytes) by value, which exceeds the low threshold of 128 bytes.

Reviewed By: erichkeane, aaron.ballman

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

show more ...

[NFC][Profile] Access profile through VirtualFileSystem

Make the access to profile data going through virtual file system so the
inputs can be remapped. In the context of the caching, it can make su

[NFC][Profile] Access profile through VirtualFileSystem

Make the access to profile data going through virtual file system so the
inputs can be remapped. In the context of the caching, it can make sure
we capture the inputs and provided an immutable input as profile data.

Reviewed By: akyrtzi, benlangmuir

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

show more ...

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

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] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
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 ...

[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 ...

Return None instead of Optional<T>() (NFC)

This patch replaces:

return Optional<T>();

with:

return None;

to make the migration from llvm::Optional to std::optional easier.
Specifically, I ca

Return None instead of Optional<T>() (NFC)

This patch replaces:

return Optional<T>();

with:

return None;

to make the migration from llvm::Optional to std::optional easier.
Specifically, I can deprecate None (in my source tree, that is) to
identify all the instances of None that should be replaced with
std::nullopt.

Note that "return None" far outnumbers "return Optional<T>();". There
are more than 2000 instances of "return None" in our source tree.

All of the instances in this patch come from functions that return
Optional<T> except Archive::findSym and ASTNodeImporter::import, where
we return Expected<Optional<T>>. Note that we can construct
Expected<Optional<T>> from any parameter convertible to Optional<T>,
which None certainly is.

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

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

show more ...

clang: Fix unnecessary truncation of resource limit values

Explicitly initialize opaque pointer mode in CodeGenAction

Explicitly call `LLVMContext::setOpaquePointers` in `CodeGenAction`
before loading any IR files. With this we use the mode specified on the

Explicitly initialize opaque pointer mode in CodeGenAction

Explicitly call `LLVMContext::setOpaquePointers` in `CodeGenAction`
before loading any IR files. With this we use the mode specified on the
command-line rather than lazily initializing it based on the contents of
the IR.

This helps when using `-fthinlto-index` which may end up mixing files
with typed and opaque pointer types which fails when the first file
happened to use typed pointers since we cannot downgrade IR with opaque
pointer types to typed pointer types.

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

show more ...

clang: Improve errors for DiagnosticInfoResourceLimit

Print source location info and demangle the name, compared
to the default behavior.

Several observations:

1. Specially handling this seems to

clang: Improve errors for DiagnosticInfoResourceLimit

Print source location info and demangle the name, compared
to the default behavior.

Several observations:

1. Specially handling this seems to give source locations
without enabling debug info, and also gives columns compared
to the backend diagnostic.

2. We're duplicating diagnostic effort in DiagnosticInfo
and clang. This feels wrong, but clang can demangle and I guess
have better debug info available? Should clang really have any of this
code? For the purposes of this diagnostic, the important piece
is just reading the source location out of the llvm::Function.

3. lld is not duplicating the same effort as clang with LTO, and
just directly printing the DiagnosticInfo as-is. e.g.

$ clang -fgpu-rdc
lld: error: local memory (480000) exceeds limit (65536) in function '_Z12use_huge_ldsIiEvv'
lld: error: local memory (960000) exceeds limit (65536) in function '_Z12use_huge_ldsIdEvv'

$ clang -fno-gpu-rdc
backend-resource-limit-diagnostics.hip:8:17: error: local memory (480000) exceeds limit (65536) in 'void use_huge_lds<int>()'
__global__ void use_huge_lds() {
^
backend-resource-limit-diagnostics.hip:8:17: error: local memory (960000) exceeds limit (65536) in 'void use_huge_lds<double>()'
2 errors generated when compiling for gfx90a.

4. Backend errors are not observed with -save-temps and -fno-gpu-rdc or -flto,
and the compile incorrectly succeeds.

5. The backend version prints error: <location info>; clang prints <location info>: error:

6. -emit-codegen-only is totally broken for AMDGPU. MC
gets a null target streamer. I do not understand why this
is a thing. This just creates a horrible edge case.
Just work around this by emitting actual code instead of blocking
this patch.

show more ...

[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

[Clang] Always set opaque pointers mode

Always set the opaque pointers mode, to make sure that
-no-opaque-pointers continues working when the default on the LLVM
side is flipped.

[misexpect] Re-implement MisExpect Diagnostics

Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.

New checks

[misexpect] Re-implement MisExpect Diagnostics

Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.

New checks rely on 2 invariants:

1) For frontend instrumentation, MD_prof branch_weights will always be
populated before llvm.expect intrinsics are lowered.

2) for IR and sample profiling, llvm.expect intrinsics will always be
lowered before branch_weights are populated from the IR profiles.

These invariants allow the checking to assume how the existing branch
weights are populated depending on the profiling method used, and emit
the correct diagnostics. If these invariants are ever invalidated, the
MisExpect related checks would need to be updated, potentially by
re-introducing MD_misexpect metadata, and ensuring it always will be
transformed the same way as branch_weights in other optimization passes.

Frontend based profiling is now enabled without using LLVM Args, by
introducing a new CodeGen option, and checking if the -Wmisexpect flag
has been passed on the command line.

Reviewed By: tejohnson

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

show more ...

[LLVMContext] Replace enableOpaquePointers() with setOpaquePointers()

This allows both explicitly enabling and explicitly disabling
opaque pointers, in anticipation of the default switching at some

[LLVMContext] Replace enableOpaquePointers() with setOpaquePointers()

This allows both explicitly enabling and explicitly disabling
opaque pointers, in anticipation of the default switching at some
point.

This also slightly changes the rules by allowing calls if either
the opaque pointer mode has not yet been set (explicitly or
implicitly) or if the value remains unchanged.

show more ...

[OpaquePtrs][Clang] Add -opaque-pointers/-no-opaque-pointers cc1 options

This adds cc1 options for enabling and disabling opaque pointers
on the clang side. This is not super useful now (because
-ml

[OpaquePtrs][Clang] Add -opaque-pointers/-no-opaque-pointers cc1 options

This adds cc1 options for enabling and disabling opaque pointers
on the clang side. This is not super useful now (because
-mllvm -opaque-pointers and -Xclang -opaque-pointers have the same
visible effect) but will be important once opaque pointers are
enabled by default in clang. In that case, it will only be
possible to disable them using the cc1 -no-opaque-pointers option.

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

show more ...

Revert "[misexpect] Re-implement MisExpect Diagnostics"

This reverts commit 46774df307159444d65083c2fd82f8574f0ab1d9.

[misexpect] Re-implement MisExpect Diagnostics

Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.

New checks

[misexpect] Re-implement MisExpect Diagnostics

Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.

New checks rely on 2 invariants:

1) For frontend instrumentation, MD_prof branch_weights will always be
populated before llvm.expect intrinsics are lowered.

2) for IR and sample profiling, llvm.expect intrinsics will always be
lowered before branch_weights are populated from the IR profiles.

These invariants allow the checking to assume how the existing branch
weights are populated depending on the profiling method used, and emit
the correct diagnostics. If these invariants are ever invalidated, the
MisExpect related checks would need to be updated, potentially by
re-introducing MD_misexpect metadata, and ensuring it always will be
transformed the same way as branch_weights in other optimization passes.

Frontend based profiling is now enabled without using LLVM Args, by
introducing a new CodeGen option, and checking if the -Wmisexpect flag
has been passed on the command line.

Reviewed By: tejohnson

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

show more ...