aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-02-10[NFC][TargetParser] Replace uses of llvm/Support/Host.hArchibald Elliott1-1/+1
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.
2023-02-08[clang][cli] Simplify repetitive macro invocationsJan Svoboda1-197/+56
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
2023-02-08[clang][deps] Ensure module invocation can be serializedBen Langmuir1-27/+66
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
2023-02-07[NFC][TargetParser] Remove llvm/ADT/Triple.hArchibald Elliott1-1/+1
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.
2023-02-01[Clang] avoid relying on StringMap iteration order when roundtripping ↵Erik Desjardins1-4/+10
-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
2023-02-01[NFC][Profile] Access profile through VirtualFileSystemSteven Wu1-6/+15
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
2023-01-19Revert "[Clang] Give Clang the ability to use a shared stat cache"Fred Riss1-27/+1
This reverts commit c5abe893120b115907376359a5809229a9f9608a. This reverts commit a033dbbe5c43247b60869b008e67ed86ed230eaa. This broke the build with -DLLVM_LINK_LLVM_DYLIB=ON. Reverting while I investigate.
2023-01-18[Clang] Give Clang the ability to use a shared stat cacheFred Riss1-1/+27
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
2023-01-14[clang] Remove remaining uses of llvm::Optional (NFC)Kazu Hirata1-1/+0
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
2023-01-14[clang] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata1-4/+5
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
2022-12-22Remove incorrectly implemented -mibt-sealFangrui Song1-6/+0
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
2022-12-17std::optional::value => operator*/operator->Fangrui Song1-2/+2
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.
2022-12-10Don't include None.h (NFC)Kazu Hirata1-1/+0
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
2022-12-09[Frontend] Use std::optional in CompilerInvocation.cpp (NFC)Kazu Hirata1-32/+36
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
2022-12-07Add support for a backdoor driver option that enables emitting headerAkira Hatanaka1-0/+10
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
2022-12-05[IR] llvm::Optional => std::optionalFangrui Song1-1/+1
Many llvm/IR/* files have been migrated by other contributors. This migrates most remaining files.
2022-12-03[clang] Use std::nullopt instead of None (NFC)Kazu Hirata1-24/+26
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
2022-12-02[clang][modules] Serialize VFS overlay paths into PCMsJan Svoboda1-2/+9
With implicitly built modules, the importing `CompilerInstance` assumes PCMs were built in a "compatible way" (i.e. with similarly set up instance). Either because their context hash matches, or because this instance has just built them. There are some use-cases, however, where this assumption doesn't hold, libclang/c-index-test being one of them. There, the importing instance (or `ASTUnit`) is being set up while the PCM file is being deserialized. Until now, we've assumed the serialized paths to input files are the actual on-disk files, meaning the default physical VFS was always able to resolve them. This won't be the case after D135636. Therefore, this patch makes sure `ASTUnit` is initialized with the same VFS as the PCM it's deserializing - by storing paths to the VFS overlay files into the PCM itself. For the VFS overlay files to be adopted at the very start of PCM deserialization, they are stored in a new section in the unhashed control block, together with header search paths and system header prefixes. The move to the unhashed control block should be safe: if two modules were built with different header search paths and they produced different results, the hashed part of the PCM file will reflect that. Reviewed By: akyrtzi, benlangmuir Differential Revision: https://reviews.llvm.org/D135634
2022-11-25[analyzer] Deprecate FAM analyzer-config, recommend -fstrict-flex-arrays insteadBalazs Benics1-0/+9
By default, clang assumes that all trailing array objects could be a FAM. So, an array of undefined size, size 0, size 1, or even size 42 is considered as FAMs for optimizations at least. One needs to override the default behavior by supplying the `-fstrict-flex-arrays=<N>` flag, with `N > 0` value to reduce the set of FAM candidates. Value `3` is the most restrictive and `0` is the most permissive on this scale. 0: all trailing arrays are FAMs 1: only incomplete, zero and one-element arrays are FAMs 2: only incomplete, zero-element arrays are FAMs 3: only incomplete arrays are FAMs If the user is happy with consdering single-element arrays as FAMs, they just need to remove the `consider-single-element-arrays-as-flexible-array-members` from the command line. Otherwise, if they don't want to recognize such cases as FAMs, they should specify `-fstrict-flex-arrays` anyway, which will be picked up by CSA. Any use of the deprecated analyzer-config value will trigger a warning explaining what to use instead. The `-analyzer-config-help` is updated accordingly. Depends on D138657 Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D138659
2022-11-21Remove -cc1 -fconcepts-ts flagErich Keane1-3/+0
The -fconcepts-ts flag has been deprecated for 5 releases now, so just remove it, concepts is supported in C++20 mode.
2022-11-18[C++20] [Modules] Remove unmaintained Header ModuleChuanqi Xu1-2/+0
Currently there is a -emit-header-module mode, which can combine several headers together as a module interface. However, this breaks our assumption (for standard c++ modules) about module interface. The module interface should come from a module interface unit. And if it is a header, it should be a header unit. And currently we have no ideas to combine several headers together. So I think this mode is an experimental one and it is not maintained and it is not used. So it will be better to remove them. Reviewed By: Bigcheese, dblaikie, bruno Differential Revision: https://reviews.llvm.org/D137609
2022-11-11The handling of 'funsafe-math-optimizations' doesn't update the 'MathErrno'Zahira Ammarguellat1-1/+1
flag. But the driver checks for 'fno-math-errno' before passing 'funsafe-math-optimizations' to the FE. In GCC, the option 'funsafe-math-optimizations' doesn't affect the 'fmath-errno' flag. This patch aligns clang with GCC. '-ffast-math' sets the FPContract to 'fast'. But 'funsafe-math-optimizations' the driver doesn't consider the FPContract when handling the option. Unfortunately there are places in the BE that interpret unsafe math mode as allowing FMA. This patch makes -ffast-math' and 'funsafe-math-optimizations' behave similarly in regard to the setting of the FPContract. Differential Revision: https://reviews.llvm.org/D137578
2022-11-08[Driver] Refactor err_drv_unsupported_option_argument call sites to use ↵Fangrui Song1-1/+1
llvm::opt::Arg::getSpelling For `-foo=bar`, getSpelling return `-foo=` which is exactly what we need from the diagnostic. Drop `-` from the err_drv_unsupported_option_argument template. This change makes `--` long option diagnostics more convenient. Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D137659
2022-11-07[clang][NFC] Use c++17 style variable type traitsNathan James1-2/+1
This was done as a test for D137302 and it makes sense to push these changes Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D137491
2022-11-01[CodeView][clang] Add flag to disable emitting command line into CodeViewArthur Eubanks1-2/+4
In https://reviews.llvm.org/D80833, there were concerns about determinism emitting the commandline into CodeView. We're actually hitting these when running clang-cl on Linux (cross compiling) versus on Windows (e.g. -fmessage-length being inferred on terminals). Add -g[no-]codeview-command-line to enable/disable this feature. It's still on by default to preserve the current state of clang. Reviewed By: thakis, rnk Differential Revision: https://reviews.llvm.org/D136474
2022-10-26[clang] Move getenv call for SOURCE_DATE_EPOCH out of frontend NFCBen Langmuir1-2/+6
Move the check for SOURCE_DATE_EPOCH to the driver and use a cc1 option to pass it to the frontend. This avoids hidden state in the cc1 invocation and makes this env variable behave more like other env variables that clang handles in the driver. Differential Revision: https://reviews.llvm.org/D136717
2022-10-12[Frontend] Recognize environment variable SOURCE_DATE_EPOCHFangrui Song1-0/+17
See https://reproducible-builds.org/docs/source-date-epoch/ . The environment variable ``SOURCE_DATE_EPOCH`` been recognized by many compilers. In GCC, if `SOURCE_DATE_EPOCH` is set, it specifies a UNIX timestamp to be used in replacement of the current date and time in the `__DATE__` and `__TIME__` macros. Note: GCC as of today does not update `__TIMESTAMP__` (the modification time of the current source file) but https://wiki.debian.org/ReproducibleBuilds/TimestampsFromCPPMacros expresses the intention to update it. This patches parses SOURCE_DATE_EPOCH and changes all the three macros. In addition, in case gmtime/localtime returns null (e.g. on 64-bit Windows gmtime returns null when the timestamp is larger than 32536850399 (3001-01-19T21:59:59Z)), use `??? ?? ????` as used by GCC. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D135045
2022-09-23Restore "[MemProf] Memprof profile matching and annotation"Teresa Johnson1-1/+4
This reverts commit 794b7ea960ccc3222f2af582efadbc5e5c464292, and thus restores commit a212d8da94d08e229aa8d65283e4b116310bba10, and follow on fixes 0cd6763fa93159b84d70a5bb602c24996acaafaa, e9ff53d42feac7fc157718523275619a8106f2f3, and 37c6a25e9ab230e5e21fa34e246d9fec55275df0. Use a hash function (BLAKE3) instead of hash_combine/hash_code which are not guaranteed to be stable across executions. Additionally, it adds a "REQUIRES: x86_64-linux" to the tests that have raw profile inputs to avoid failures on big endian bots. Reviewers: snehasish, davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D128142
2022-09-22Revert "[MemProf] Memprof profile matching and annotation"Teresa Johnson1-4/+1
This reverts commit a212d8da94d08e229aa8d65283e4b116310bba10, and follow on fixes 0cd6763fa93159b84d70a5bb602c24996acaafaa, e9ff53d42feac7fc157718523275619a8106f2f3, and 37c6a25e9ab230e5e21fa34e246d9fec55275df0. After re-reading the documentation for hash_combine, I don't think this is the appropriate hash function to use for computing the hash to use as a stack id in the metadata, since it is not guaranteed to produce stable values across executions. I have not hit this problem, but plan to switch to using an MD5 hash. I am hitting an issue with one of the bots (https://lab.llvm.org/buildbot/#/builders/171/builds/20732) where the values produced are only the lower 32 bits of the expected hash values, however, which I assume is related to the implementation of hash_combine and hash_code. I believe I fixed all of the other bot failures with the follow on fixes, which I'll merge into the new version before reapplying.
2022-09-22[MemProf] Memprof profile matching and annotationTeresa Johnson1-1/+4
Profile matching and IR annotation for memprof profiles. See also related RFCs: RFC: Sanitizer-based Heap Profiler [1] RFC: A binary serialization format for MemProf [2] RFC: IR metadata format for MemProf [3]* * Note that the IR metadata format has changed from the RFC during implementation, as described in the preceeding patch adding the basic metadata and verification support. The matching is performed during the normal PGO annotation phase, to ensure that the inlines applied in the IR at that point are a subset of the inlines in the profiled binary and thus reflected in the profile's call stacks. This is important because the call frames are associated with functions in the profile based on the inlining in the symbolized call stacks, and this simplifies locating the subset of profile data relevant for matching onto each function's IR. The PGOInstrumentationUse pass is enhanced to perform matching for whatever combination of memprof and regular PGO profile data exists in the profile. Using the utilities introduced in D128854: The memprof profile data for each context is converted to "cold" or "notcold" based on parameterized thresholds for size, access count, and lifetime. The memprof allocation contexts are trimmed to the minimal amount of context required to uniquely identify whether the context is cold or not cold. For allocations where all profiled contexts have the same allocation type, no memprof metadata is attached and instead the allocation call is directly annotated with an attribute specifying the alloction type. This is the same attributed that will be applied to allocation calls once cloned for different contexts, and later used during LibCall simplification to emit allocation hints [4]. Depends on D128141 and D128854. [1] https://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html [2] https://lists.llvm.org/pipermail/llvm-dev/2021-September/153007.html [3] https://discourse.llvm.org/t/rfc-ir-metadata-format-for-memprof/59165 [4] https://github.com/google/tcmalloc/commit/ab87cf382dc56784f783f3aaa43d6d0465d5f385 Differential Revision: https://reviews.llvm.org/D128142
2022-09-16[Clang] Give error message for invalid profile path when compiling IRAiden Grossman1-5/+8
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
2022-09-14[OpenMP] Remove simplified device runtime handlingJoseph Huber1-8/+0
The old device runtime had a "simplified" version that prevented many of the runtime features from being initialized. The old device runtime was deleted in LLVM 14 and is no longer in use. Selectively deactivating features is now done using specific flags rather than the old technique. This patch simply removes the extra logic required for handling the old simple runtime scheme. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D133802
2022-09-13[clang] Explicitly set the EmulatedTLS codegen option. NFC.Martin Storsjö1-10/+5
Set the EmulatedTLS option based on `Triple::hasDefaultEmulatedTLS()` if the user didn't specify it; set `ExplicitEmulatedTLS` to true in `llvm::TargetOptions` and set `EmulatedTLS` to Clang's opinion of what the default or preference is. This avoids any risk of deviance between the two. This affects one check of `getCodeGenOpts().EmulatedTLS` in `shouldAssumeDSOLocal` in CodeGenModule, but as that check only is done for `TT.isWindowsGNUEnvironment()`, and `hasDefaultEmulatedTLS()` returns false for such environments it doesn't make any current testable difference - thus NFC. Some mingw distributions carry a downstream patch, that enables emulated TLS by default for mingw targets in `hasDefaultEmulatedTLS()` - and for such cases, this patch does make a difference and fixes the detection of emulated TLS, if it is implicitly enabled. Differential Revision: https://reviews.llvm.org/D132916
2022-09-02[HLSL] Restrict to supported targetsChris Bieneman1-0/+8
Someday we would like to support HLSL on a wider range of targets, but today targeting anything other than `dxil` is likly to cause lots of headaches. This adds an error and tests to validate that the expected target is `dxil-?-shadermodel`. We will continue to do a best effort to ensure the code we write makes it easy to support other targets (like SPIR-V), but this error will prevent users from hitting frustrating errors for unsupported cases. Reviewed By: jcranmer-intel, Anastasia Differential Revision: https://reviews.llvm.org/D132056
2022-08-23[Clang] follow-up D128745, use ClangABICompat15 instead of ClangABICompat14Yuanfang Chen1-0/+4
Since the patch missed release 15.x and will be included in release 16.x. Also, simplify related tests. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D132414
2022-08-23[analyzer] Drop deprecated flagsBalazs Benics1-8/+0
As proposed in D126215 (ffe7950ebc62380c3afc7c71f454a1db3f6f5c76), I'm dropping the `-analyzer-store` and `-analyzer-opt-analyze-nested-blocks` clang frontend flags. I'm also dropping the corresponding commandline handlers of `scanbuild`. This behavior is planned to be part of `clang-16`. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D132289
2022-08-23[clang] Pull some utility functions into CompilerInvocation NFCBen Langmuir1-0/+31
Move copying compiler arguments to a vector<string> and modifying common module-related options into CompilerInvocation in preparation for using some of them in more places and to avoid duplicating this code accidentally in the future. Differential Revision: https://reviews.llvm.org/D132419
2022-08-20Revert "Use std::is_same_v instead of std::is_same (NFC)"Kazu Hirata1-1/+2
This reverts commit c5da37e42d388947a40654b7011f2a820ec51601. This patch seems to break builds with some versions of MSVC.
2022-08-20Use std::is_same_v instead of std::is_same (NFC)Kazu Hirata1-2/+1
2022-08-17[clang][llvm][NFC] Change misexpect's tolerance option to be 32-bitPaul Kirth1-2/+2
In D131869 we noticed that we jump through some hoops because we parse the tolerance option used in MisExpect.cpp into a 64-bit integer. This is unnecessary, since the value can only be in the range [0, 100). This patch changes the underlying type to be 32-bit from where it is parsed in Clang through to it's use in LLVM. Reviewed By: jloser Differential Revision: https://reviews.llvm.org/D131935
2022-08-04[HLSL] Support -E option for HLSL.Xiang Li1-0/+4
-E option will set entry function for hlsl. The format is -E entry_name. To avoid conflict with existing option with name 'E', add an extra prefix '--'. A new field HLSLEntry is added to TargetOption. To share code with HLSLShaderAttr, entry function will be add HLSLShaderAttr attribute too. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D124751
2022-07-29Fix lack of cc1 flag in llvmcmd sections when assertions are enabledAiden Grossman1-1/+4
Currently when assertions are enabled, the cc1 flag is not inserted into the llvmcmd section of object files with embedded bitcode. This deviates from the normal behavior where this is the first flag that is inserted. This error stems from incorrect use of the function generateCC1CommandLine() which requires manually adding in the -cc1 flag which is currently not done. Reviewed By: jansvoboda11 Differential Revision: https://reviews.llvm.org/D130620
2022-07-27[clang][AIX] Add option to control quadword lock free atomics ABI on AIXKai Luo1-0/+6
We are supporting quadword lock free atomics on AIX. For the situation that users on AIX are using a libatomic that is lock-based for quadword types, we can't enable quadword lock free atomics by default on AIX in case user's new code and existing code accessing the same shared atomic quadword variable, we can't guarentee atomicity. So we need an option to enable quadword lock free atomics on AIX, thus we can build a quadword lock-free libatomic(also for advanced users considering atomic performance critical) for users to make the transition smooth. Reviewed By: shchenz Differential Revision: https://reviews.llvm.org/D127189
2022-07-13[clang] Use value instead of getValue (NFC)Kazu Hirata1-2/+2
2022-07-12[X86] initial -mfunction-return=thunk-extern supportNick Desaulniers1-0/+24
Adds support for: * `-mfunction-return=<value>` command line flag, and * `__attribute__((function_return("<value>")))` function attribute Where the supported <value>s are: * keep (disable) * thunk-extern (enable) thunk-extern enables clang to change ret instructions into jmps to an external symbol named __x86_return_thunk, implemented as a new MachineFunctionPass named "x86-return-thunks", keyed off the new IR attribute fn_ret_thunk_extern. The symbol __x86_return_thunk is expected to be provided by the runtime the compiled code is linked against and is not defined by the compiler. Enabling this option alone doesn't provide mitigations without corresponding definitions of __x86_return_thunk! This new MachineFunctionPass is very similar to "x86-lvi-ret". The <value>s "thunk" and "thunk-inline" are currently unsupported. It's not clear yet that they are necessary: whether the thunk pattern they would emit is beneficial or used anywhere. Should the <value>s "thunk" and "thunk-inline" become necessary, x86-return-thunks could probably be merged into x86-retpoline-thunks which has pre-existing machinery for emitting thunks (which could be used to implement the <value> "thunk"). Has been found to build+boot with corresponding Linux kernel patches. This helps the Linux kernel mitigate RETBLEED. * CVE-2022-23816 * CVE-2022-28693 * CVE-2022-29901 See also: * "RETBLEED: Arbitrary Speculative Code Execution with Return Instructions." * AMD SECURITY NOTICE AMD-SN-1037: AMD CPU Branch Type Confusion * TECHNICAL GUIDANCE FOR MITIGATING BRANCH TYPE CONFUSION REVISION 1.0 2022-07-12 * Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 SystemZ may eventually want to support "thunk-extern" and "thunk"; both options are used by the Linux kernel's CONFIG_EXPOLINE. This functionality has been available in GCC since the 8.1 release, and was backported to the 7.3 release. Many thanks for folks that provided discrete review off list due to the embargoed nature of this hardware vulnerability. Many Bothans died to bring us this information. Link: https://www.youtube.com/watch?v=IF6HbCKQHK8 Link: https://github.com/llvm/llvm-project/issues/54404 Link: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-01/msg01197.html Link: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html Link: https://arstechnica.com/information-technology/2022/07/intel-and-amd-cpus-vulnerable-to-a-new-speculative-execution-attack/?comments=1 Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce114c866860aa9eae3f50974efc68241186ba60 Link: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00702.html Link: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00707.html Reviewed By: aaron.ballman, craig.topper Differential Revision: https://reviews.llvm.org/D129572
2022-06-25[clang] Don't use Optional::hasValue (NFC)Kazu Hirata1-4/+4
This patch replaces Optional::hasValue with the implicit cast to bool in conditionals only.
2022-06-25Revert "Don't use Optional::hasValue (NFC)"Kazu Hirata1-6/+6
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25Don't use Optional::hasValue (NFC)Kazu Hirata1-6/+6
2022-06-24Revert "DebugInfo: Fully integrate ctor type homing into 'limited' debug info"David Blaikie1-0/+16
Reverting to simplify some Google-internal rollout issues. Will recommit in a week or two. This reverts commit 517bbc64dbe493644eff8d55fd9566435e930520.
2022-06-23DebugInfo: Fully integrate ctor type homing into 'limited' debug infoDavid Blaikie1-16/+0
Simplify debug info back to just "limited" or "full" by rolling the ctor type homing fully into the "limited" debug info. Also fix a bug I found along the way that was causing ctor type homing to kick in even when something could be vtable homed (where vtable homing is stronger/more effective than ctor homing) - fixing at the same time as it keeps the tests (that were testing only "limited non ctor" homing and now test ctor homing) passing.
generated by cgit v1.1 at 2025-10-05 00:24:33 +0000