[AIX][clang] Storage Locations for Constant Pointers

This patch adds clang options `-mxcoff-roptr` and `-mno-xcoff-roptr` to specify storage locations for constant pointers on AIX.

When the `-mxcof

[AIX][clang] Storage Locations for Constant Pointers

This patch adds clang options `-mxcoff-roptr` and `-mno-xcoff-roptr` to specify storage locations for constant pointers on AIX.

When the `-mxcoff-roptr` option is in effect, constant pointers, virtual function tables, and virtual type tables are placed in read-only storage. When the `-mno-xcoff-roptr` option is in effect, pointers, virtual function tables, and virtual type tables are placed are placed in read/write storage.

This patch depends on https://reviews.llvm.org/D144189.

Reviewed By: hubert.reinterpretcast, stephenpeckham

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

show more ...

[clang] Apply -fcoverage-prefix-map reverse order

This patch changes handling multiple -fcoverage-prefix-map options to
match GCC's behavior. GCC applies prefix remappings that are provided
in rever

[clang] Apply -fcoverage-prefix-map reverse order

This patch changes handling multiple -fcoverage-prefix-map options to
match GCC's behavior. GCC applies prefix remappings that are provided
in reverse order (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591).

Reviewed By: phosek

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

show more ...

-fdebug-prefix-map=: make the last win when multiple prefixes match

For
`clang -c -g -fdebug-prefix-map=a/b=y -fdebug-prefix-map=a=x a/b/c.c`,
we apply the longest prefix substitution, but
GCC has a

-fdebug-prefix-map=: make the last win when multiple prefixes match

For
`clang -c -g -fdebug-prefix-map=a/b=y -fdebug-prefix-map=a=x a/b/c.c`,
we apply the longest prefix substitution, but
GCC has always been picking the last applicable option (`a=x`, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591).

I feel that GCC's behavior is reasonable given the convention that the last
value wins for the same option.

Before D49466, Clang appeared to apply the shortest prefix substitution,
which likely made the least sense.

Reviewed By: #debug-info, scott.linder

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

show more ...

[Driver] Simplify handling of -mabi=vec-default -mabi=vec-extabi

And fix a minor issue that -mabi=vec-extabi -mabi=vec-default should not pass
"-bplugin_opt:-vec-extabi" to ld.

[Clang] Accept and forward `-fconvergent-functions` in the driver

Currently the `-fconvergent-functions` option is primarily used by GPU
toolchains to enforce convergent operations in line with the

[Clang] Accept and forward `-fconvergent-functions` in the driver

Currently the `-fconvergent-functions` option is primarily used by GPU
toolchains to enforce convergent operations in line with the semantics.
This option previously was only supported via `-Xclang` and would show
up as unused if passed to the driver. This patch allows the driver to
forward it. This is mostly useful for users wishing to target GPU
toolchains directly via `--target=` without an offloading runtime.

Reviewed By: JonChesterfield, MaskRay

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

show more ...

Remove ExplicitEmulatedTLS and simplify -femulated-tls handling

Currently clangDriver passes -femulated-tls and -fno-emulated-tls to cc1.
cc1 forwards the option to LLVMCodeGen and ExplicitEmulatedT

Remove ExplicitEmulatedTLS and simplify -femulated-tls handling

Currently clangDriver passes -femulated-tls and -fno-emulated-tls to cc1.
cc1 forwards the option to LLVMCodeGen and ExplicitEmulatedTLS is used
to decide the value. Simplify this by moving the Clang decision to
clangDriver and moving the LLVM decision to InitTargetOptionsFromCodeGenFlags.

show more ...

[NFC][Clang] Move DebugOptions to llvm/Frontend for reuse in Flang

This patch moves the Debug Options to llvm/Frontend so that it can be shared by Flang as well.

Reviewed By: kiranchandramohan, awa

[NFC][Clang] Move DebugOptions to llvm/Frontend for reuse in Flang

This patch moves the Debug Options to llvm/Frontend so that it can be shared by Flang as well.

Reviewed By: kiranchandramohan, awarzynski

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

show more ...

[Driver] Add --vfsoverlay flag

This flag implies `-ivfsoverlay`, and additionally passes the same
argument to the linker if it supports it. At present the only linker
which does is lld-link, so this

[Driver] Add --vfsoverlay flag

This flag implies `-ivfsoverlay`, and additionally passes the same
argument to the linker if it supports it. At present the only linker
which does is lld-link, so this functionality has only been added to
the MSVC toolchain. Additionally this option has been made a
CoreOption so that clang-cl can use it without `-Xclang`

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

show more ...

[NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC w

[NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.

show more ...

[clang][cli] Simplify repetitive macro invocations

Since we now only support Visual Studio 2019 16.7 and newer, we're able to use the `/Zc:preprocessor` flag that turns on the standards-conforming p

[clang][cli] Simplify repetitive macro invocations

Since we now only support Visual Studio 2019 16.7 and newer, we're able to use the `/Zc:preprocessor` flag that turns on the standards-conforming preprocessor. It (among other things) correctly expands `__VA_ARGS__` (see https://learn.microsoft.com/en-us/cpp/preprocessor/preprocessor-experimental-overview?view=msvc-170#macro-arguments-are-unpacked). This enables us to get rid of some repetitive boilerplate in Clang's command-line parser/generator.

Reviewed By: Bigcheese

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

show more ...

[clang][deps] Ensure module invocation can be serialized

When reseting modular options, propagate the values from certain options
that have ImpliedBy relations instead of setting to the default. Als

[clang][deps] Ensure module invocation can be serialized

When reseting modular options, propagate the values from certain options
that have ImpliedBy relations instead of setting to the default. Also,
verify in clang-scan-deps that the command line produced round trips
exactly.

Ideally we would automatically derive the set of options that need this
kind of propagation, but for now there aren't very many impacted.

rdar://105148590

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

show more ...

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

[Clang] avoid relying on StringMap iteration order when roundtripping -analyzer-config

I am working on another patch that changes StringMap's hash function,
which changes the iteration order here, a

[Clang] avoid relying on StringMap iteration order when roundtripping -analyzer-config

I am working on another patch that changes StringMap's hash function,
which changes the iteration order here, and breaks some tests,
specifically:

clang/test/Analysis/NSString.m
clang/test/Analysis/shallow-mode.m

with errors like:

generated arguments do not match in round-trip
generated arguments #1 in round-trip: <...> "-analyzer-config" "ipa=inlining" "-analyzer-config" "max-nodes=75000" <...>
generated arguments #2 in round-trip: <...> "-analyzer-config" "max-nodes=75000" "-analyzer-config" "ipa=inlining" <...>

To avoid this, sort the options by key, instead of using the default map
iteration order.

Reviewed By: jansvoboda11, MaskRay

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

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

Revert "[Clang] Give Clang the ability to use a shared stat cache"

This reverts commit c5abe893120b115907376359a5809229a9f9608a.
This reverts commit a033dbbe5c43247b60869b008e67ed86ed230eaa.

This b

Revert "[Clang] Give Clang the ability to use a shared stat cache"

This reverts commit c5abe893120b115907376359a5809229a9f9608a.
This reverts commit a033dbbe5c43247b60869b008e67ed86ed230eaa.

This broke the build with -DLLVM_LINK_LLVM_DYLIB=ON. Reverting while I
investigate.

show more ...

[Clang] Give Clang the ability to use a shared stat cache

Every Clang instance uses an internal FileSystemStatCache to avoid
stating the same content multiple times. However, different instances
of

[Clang] Give Clang the ability to use a shared stat cache

Every Clang instance uses an internal FileSystemStatCache to avoid
stating the same content multiple times. However, different instances
of Clang will contend for filesystem access for their initial stats
during HeaderSearch or module validation.

On some workloads, the time spent in the kernel in these concurrent
stat calls has been measured to be over 20% of the overall compilation
time. This is extremly wassteful when most of the stat calls target
mostly immutable content like a SDK.

This commit introduces a new tool `clang-stat-cache` able to generate
an OnDiskHashmap containing the stat data for a given filesystem
hierarchy.

The driver part of this has been modeled after -ivfsoverlay given
the similarities with what it influences. It introduces a new
-ivfsstatcache driver option to instruct Clang to use a stat cache
generated by `clang-stat-cache`. These stat caches are inserted at
the bottom of the VFS stack (right above the real filesystem).

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

show more ...

[clang] Remove remaining uses of llvm::Optional (NFC)

This patch removes several "using" declarations and #include
"llvm/ADT/Optional.h".

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

[clang] Remove remaining uses of llvm::Optional (NFC)

This patch removes several "using" declarations and #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] 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 ...

Remove incorrectly implemented -mibt-seal

The option from D116070 does not work as intended and will not be needed when
hidden visibility is used. A function needs ENDBR if it may be reached
indirec

Remove incorrectly implemented -mibt-seal

The option from D116070 does not work as intended and will not be needed when
hidden visibility is used. A function needs ENDBR if it may be reached
indirectly. If we make ThinLTO combine the address-taken property (close to
`!GV.use_empty() && !GV.hasAtLeastLocalUnnamedAddr()`), then the condition can
be expressed with:

`AddressTaken || (!F.hasLocalLinkage() && (VisibleToRegularObj || !F.hasHiddenVisibility()))`

The current `F.hasAddressTaken()` condition does not take into acount of
address-significance in another bitcode file or ELF relocatable file.

For the Linux kernel, it uses relocatable linking. lld/ELF uses a
conservative approach by setting all `VisibleToRegularObj` to true.
Using the non-relocatable semantics may under-estimate
`VisibleToRegularObj`. As @pcc mentioned on
https://github.com/ClangBuiltLinux/linux/issues/1737#issuecomment-1343414686
, we probably need a symbol list to supply additional
`VisibleToRegularObj` symbols (not part of the relocatable LTO link).

Reviewed By: samitolvanen

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

show more ...

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_E

std::optional::value => operator*/operator->

value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).

This fixes clang.

show more ...

Don't include None.h (NFC)

I've converted all known uses of None to std::nullopt, so we no longer
need to include None.h.

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

Don't include None.h (NFC)

I've converted all known uses of None to std::nullopt, so we no longer
need to include None.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 ...

[Frontend] Use std::optional in CompilerInvocation.cpp (NFC)

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

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasv

[Frontend] Use std::optional in CompilerInvocation.cpp (NFC)

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

Add support for a backdoor driver option that enables emitting header
usage information in JSON to a file

Each line in the file is a JSON object that has the name of the main
source file followed by

Add support for a backdoor driver option that enables emitting header
usage information in JSON to a file

Each line in the file is a JSON object that has the name of the main
source file followed by the list of system header files included
directly or indirectly from that file.

For example:

{"source":"/tmp/foo.c",
"includes":["/usr/include/stdio.h", "/usr/include/stdlib.h"]}

To reduce the amount of data written to the file, only the system
headers that are directly included from a non-system header file are
recorded.

In order to emit the header information in JSON, it is necessary to set
the following environment variables:

CC_PRINT_HEADERS_FORMAT=json CC_PRINT_HEADERS_FILTERING=only-direct-system

The following combination is equivalent to setting CC_PRINT_HEADERS=1:

CC_PRINT_HEADERS_FORMAT=textual CC_PRINT_HEADERS_FILTERING=none

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

show more ...

[IR] llvm::Optional => std::optional

Many llvm/IR/* files have been migrated by other contributors.
This migrates most remaining files.

[clang] 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 m

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