#
5834996f |
| 18-Nov-2020 |
Ben Barham <ben_barham@apple.com> |
[Frontend] Add flag to allow PCM generation despite compiler errors
As with precompiled headers, it's useful for indexers to be able to continue through compiler errors in dependent modules.
Resolv
[Frontend] Add flag to allow PCM generation despite compiler errors
As with precompiled headers, it's useful for indexers to be able to continue through compiler errors in dependent modules.
Resolves rdar://69816264
Reviewed By: akyrtzi
Differential Revision: https://reviews.llvm.org/D91580
show more ...
|
#
3f4b5893 |
| 16-Nov-2020 |
Yaxun (Sam) Liu <yaxun.liu@amd.com> |
[AMDGPU] Add option -munsafe-fp-atomics
Add an option -munsafe-fp-atomics for AMDGPU target.
When enabled, clang adds function attribute "amdgpu-unsafe-fp-atomics" to any functions for amdgpu targe
[AMDGPU] Add option -munsafe-fp-atomics
Add an option -munsafe-fp-atomics for AMDGPU target.
When enabled, clang adds function attribute "amdgpu-unsafe-fp-atomics" to any functions for amdgpu target. This allows amdgpu backend to use unsafe fp atomic instructions in these functions.
Differential Revision: https://reviews.llvm.org/D91546
show more ...
|
#
2f3055c5 |
| 13-Nov-2020 |
Jan Svoboda <git@jansvoboda.dev> |
[clang][cli] Add support for options with two flags for controlling the same field.
This enables automatically parsing and generating CC1 arguments for options where two flags control the same field
[clang][cli] Add support for options with two flags for controlling the same field.
This enables automatically parsing and generating CC1 arguments for options where two flags control the same field, e.g. -fexperimental-new-pass-manager and -fno-experimental new pass manager.
Reviewed By: Bigcheese, dexonsmith
Original patch by Daniel Grumberg.
Differential Revision: https://reviews.llvm.org/D83071
show more ...
|
#
6861d938 |
| 14-Nov-2020 |
Roman Lebedev <lebedev.ri@gmail.com> |
Revert "clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM"
See discussion in https://bugs.llvm.org/show_bug.cgi?id=45073 / https://reviews.llvm.org/D66324#2334485 the imp
Revert "clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM"
See discussion in https://bugs.llvm.org/show_bug.cgi?id=45073 / https://reviews.llvm.org/D66324#2334485 the implementation is known-broken for certain inputs, the bugreport was up for a significant amount of timer, and there has been no activity to address it. Therefore, just completely rip out all of misexpect handling.
I suspect, fixing it requires redesigning the internals of MD_misexpect. Should anyone commit to fixing the implementation problem, starting from clean slate may be better anyways.
This reverts commit 7bdad08429411e7d0ecd58cd696b1efe3cff309e, and some of it's follow-ups, that don't stand on their own.
show more ...
|
#
d2d59d2b |
| 11-Nov-2020 |
Jan Svoboda <jan_svoboda@apple.com> |
Reland [clang][cli] Port ObjCMTAction to new option parsing system
Merge existing marhsalling info kinds and add some primitives to express flag options that contribute to a bitfield.
Depends on D8
Reland [clang][cli] Port ObjCMTAction to new option parsing system
Merge existing marhsalling info kinds and add some primitives to express flag options that contribute to a bitfield.
Depends on D82574
Original patch by Daniel Grumberg.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D82860
show more ...
|
#
ac523d2d |
| 12-Nov-2020 |
Kevin P. Neal <kevin.neal@sas.com> |
[FPEnv][Clang][Driver] Use MarshallingInfoFlag for -fexperimental-strict-floating-point
As of D80952 we are disabling strict floating point on all hosts except those that are explicitly listed as su
[FPEnv][Clang][Driver] Use MarshallingInfoFlag for -fexperimental-strict-floating-point
As of D80952 we are disabling strict floating point on all hosts except those that are explicitly listed as supported. Use of strict floating point on other hosts requires use of the -fexperimental-strict-floating-point flag. This is to avoid bugs like "https://bugs.llvm.org/show_bug.cgi?id=45329" (which has an incorrect link in the previous review).
In the review for D80952 I was asked to mark the -fexperimental option as a MarshallingInfoFlag. This patch does exactly that.
Differential Revision: https://reviews.llvm.org/D88987
show more ...
|
#
4e9af3d4 |
| 06-Nov-2020 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
Frontend: Skip namespace around createVFSFromCompilerInvocation definition, NFC
Qualify definitions with `clang::` rather than opening/closing a namespace.
Differential Revision: https://reviews.ll
Frontend: Skip namespace around createVFSFromCompilerInvocation definition, NFC
Qualify definitions with `clang::` rather than opening/closing a namespace.
Differential Revision: https://reviews.llvm.org/D90957
show more ...
|
#
f917356f |
| 11-Nov-2020 |
Mehdi Amini <joker.eph@gmail.com> |
Revert "[clang][cli] Port ObjCMTAction to new option parsing system"
This reverts commit 09248a5d25bb1c9f357247fa3da8fbe4470e9c67.
Some builds are broken. I suspect a `static constexpr` in a class
Revert "[clang][cli] Port ObjCMTAction to new option parsing system"
This reverts commit 09248a5d25bb1c9f357247fa3da8fbe4470e9c67.
Some builds are broken. I suspect a `static constexpr` in a class missing a definition out of class (required pre-c++17).
show more ...
|
#
624bced7 |
| 11-Nov-2020 |
Elvina Yakubova <elvina.yakubova@huawei.com> |
[OpenCL] Make Clang recognize -cl-std=1.0 as a value argument
This patch makes Clang recognize -cl-std=1.0 as a value argument, before only -std=cl1.0 has to be used instead.
Fixes https://bugs.llv
[OpenCL] Make Clang recognize -cl-std=1.0 as a value argument
This patch makes Clang recognize -cl-std=1.0 as a value argument, before only -std=cl1.0 has to be used instead.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47981
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D91237
show more ...
|
#
09248a5d |
| 11-Nov-2020 |
Jan Svoboda <jan_svoboda@apple.com> |
[clang][cli] Port ObjCMTAction to new option parsing system
Merge existing marhsalling info kinds and add some primitives to express flag options that contribute to a bitfield.
Depends on D82574
R
[clang][cli] Port ObjCMTAction to new option parsing system
Merge existing marhsalling info kinds and add some primitives to express flag options that contribute to a bitfield.
Depends on D82574
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D82860
show more ...
|
#
58c586e7 |
| 10-Nov-2020 |
Alexandre Rames <arames@apple.com> |
Allow searching for prebuilt implicit modules.
This reverts commit c67656b994c87224e0b33e2c4b09093986a5cfa6, and addresses the build issue.
|
#
dbfa69c5 |
| 09-Nov-2020 |
Jan Svoboda <jan_svoboda@apple.com> |
Port some floating point options to new option marshalling infrastructure
This ports a number of OpenCL and fast-math flags for floating point over to the new marshalling infrastructure.
As part of
Port some floating point options to new option marshalling infrastructure
This ports a number of OpenCL and fast-math flags for floating point over to the new marshalling infrastructure.
As part of this, `Opt{In,Out}FFlag` were enhanced to allow other flags to imply them, via `DefaultAnyOf<>`. For example: ``` defm signed_zeros : OptOutFFlag<"signed-zeros", ..., "LangOpts->NoSignedZero", DefaultAnyOf<[cl_no_signed_zeros, menable_unsafe_fp_math]>>; ``` defines `-fsigned-zeros` (`false`) and `-fno-signed-zeros` (`true`) linked to the keypath `LangOpts->NoSignedZero`, defaulting to `false`, but set to `true` implicitly if one of `-cl-no-signed-zeros` or `-menable-unsafe-fp-math` is on.
Note that the initial patch was written Daniel Grumberg.
Differential Revision: https://reviews.llvm.org/D82756
show more ...
|
#
c67656b9 |
| 06-Nov-2020 |
Stella Stamenova <stilis@microsoft.com> |
Revert "Allow searching for prebuilt implicit modules."
This reverts commit 71e108cd86e70b06c5fa3a63689dcb3555c3d13f.
This change caused a build failure on Windows: http://lab.llvm.org:8011/#/build
Revert "Allow searching for prebuilt implicit modules."
This reverts commit 71e108cd86e70b06c5fa3a63689dcb3555c3d13f.
This change caused a build failure on Windows: http://lab.llvm.org:8011/#/builders/83/builds/570
show more ...
|
#
71e108cd |
| 05-Nov-2020 |
Alexandre Rames <arames@apple.com> |
Allow searching for prebuilt implicit modules.
The behavior is controlled by the `-fprebuilt-implicit-modules` option, and allows searching for implicit modules in the prebuilt module cache paths.
Allow searching for prebuilt implicit modules.
The behavior is controlled by the `-fprebuilt-implicit-modules` option, and allows searching for implicit modules in the prebuilt module cache paths.
The current command-line options for prebuilt modules do not allow to easily maintain and use multiple versions of modules. Both the producer and users of prebuilt modules are required to know the relationships between compilation options and module file paths. Using a particular version of a prebuilt module requires passing a particular option on the command line (e.g. `-fmodule-file=[<name>=]<file>` or `-fprebuilt-module-path=<directory>`).
However the compiler already knows how to distinguish and automatically locate implicit modules. Hence this proposal to introduce the `-fprebuilt-implicit-modules` option. When set, it enables searching for implicit modules in the prebuilt module paths (specified via `-fprebuilt-module-path`). To not modify existing behavior, this search takes place after the standard search for prebuilt modules. If not
Here is a workflow illustrating how both the producer and consumer of prebuilt modules would need to know what versions of prebuilt modules are available and where they are located.
clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules_v1 <config 1 options> clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules_v2 <config 2 options> clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules_v3 <config 3 options>
clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap -fprebuilt-module-path=prebuilt_modules_v1 <config 1 options> clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap <non-prebuilt config options>
With prebuilt implicit modules, the producer can generate prebuilt modules as usual, all in the same output directory. The same mechanisms as for implicit modules take care of incorporating hashes in the path to distinguish between module versions.
Note that we do not specify the output module filename, so `-o` implicit modules are generated in the cache path `prebuilt_modules`.
clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules <config 1 options> clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules <config 2 options> clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo -fmodules-cache-path=prebuilt_modules <config 3 options>
The user can now simply enable prebuilt implicit modules and point to the prebuilt modules cache. No need to "parse" command-line options to decide what prebuilt modules (paths) to use.
clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap -fprebuilt-module-path=prebuilt_modules -fprebuilt-implicit-modules <config 1 options> clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap -fprebuilt-module-path=prebuilt_modules -fprebuilt-implicit-modules <non-prebuilt config options>
This is for example particularly useful in a use-case where compilation is expensive, and the configurations expected to be used are predictable, but not controlled by the producer of prebuilt modules. Modules for the set of predictable configurations can be prebuilt, and using them does not require "parsing" the configuration (command-line options).
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D68997
show more ...
|
#
ae9231ca |
| 02-Nov-2020 |
Ben Dunbobbin <Ben.Dunbobbin@sony.com> |
Reland - [Clang] Add the ability to map DLL storage class to visibility
415f7ee883 had LIT test failures on any build where the clang executable was not called "clang". I have adjusted the LIT CHECK
Reland - [Clang] Add the ability to map DLL storage class to visibility
415f7ee883 had LIT test failures on any build where the clang executable was not called "clang". I have adjusted the LIT CHECKs to remove the binary name to fix this.
Original commit message:
For PlayStation we offer source code compatibility with Microsoft's dllimport/export annotations; however, our file format is based on ELF.
To support this we translate from DLL storage class to ELF visibility at the end of codegen in Clang.
Other toolchains have used similar strategies (e.g. see the documentation for this ARM toolchain:
https://developer.arm.com/documentation/dui0530/i/migrating-from-rvct-v3-1-to-rvct-v4-0/changes-to-symbol-visibility-between-rvct-v3-1-and-rvct-v4-0)
This patch adds the ability to perform this translation. Options are provided to support customizing the mapping behaviour.
Differential Revision: https://reviews.llvm.org/D89970
show more ...
|
#
5024d3aa |
| 02-Nov-2020 |
Ben Dunbobbin <Ben.Dunbobbin@sony.com> |
Revert "[Clang] Add the ability to map DLL storage class to visibility"
This reverts commit 415f7ee8836944942d8beb70e982e95a312866a7.
The added tests were failing on the build bots!
|
#
415f7ee8 |
| 02-Nov-2020 |
Ben Dunbobbin <Ben.Dunbobbin@sony.com> |
[Clang] Add the ability to map DLL storage class to visibility
For PlayStation we offer source code compatibility with Microsoft's dllimport/export annotations; however, our file format is based on
[Clang] Add the ability to map DLL storage class to visibility
For PlayStation we offer source code compatibility with Microsoft's dllimport/export annotations; however, our file format is based on ELF.
To support this we translate from DLL storage class to ELF visibility at the end of codegen in Clang.
Other toolchains have used similar strategies (e.g. see the documentation for this ARM toolchain:
https://developer.arm.com/documentation/dui0530/i/migrating-from-rvct-v3-1-to-rvct-v4-0/changes-to-symbol-visibility-between-rvct-v3-1-and-rvct-v4-0)
This patch adds the ability to perform this translation. Options are provided to support customizing the mapping behaviour.
Differential Revision: https://reviews.llvm.org/D89970
show more ...
|
#
0949f96d |
| 29-Sep-2020 |
Teresa Johnson <tejohnson@google.com> |
[MemProf] Pass down memory profile name with optional path from clang
Similar to -fprofile-generate=, add -fmemory-profile= which takes a directory path. This is passed down to LLVM via a new module
[MemProf] Pass down memory profile name with optional path from clang
Similar to -fprofile-generate=, add -fmemory-profile= which takes a directory path. This is passed down to LLVM via a new module flag metadata. LLVM in turn provides this name to the runtime via the new __memprof_profile_filename variable.
Additionally, always pass a default filename (in $cwd if a directory name is not specified vi the = form of the option). This is also consistent with the behavior of the PGO instrumentation. Since the memory profiles will generally be fairly large, it doesn't make sense to dump them to stderr. Also, importantly, the memory profiles will eventually be dumped in a compact binary format, which is another reason why it does not make sense to send these to stderr by default.
Change the existing memprof tests to specify log_path=stderr when that was being relied on.
Depends on D89086.
Differential Revision: https://reviews.llvm.org/D89087
show more ...
|
#
13aee94b |
| 29-Oct-2020 |
Mircea Trofin <mtrofin@google.com> |
[ThinLTO] Fix empty .llvmcmd sections
When passing -lto-embed-bitcode=post-merge-pre-opt, we were getting empty .llvmcmd sections. It turns out that is because the CodeGenOptions::CmdArgs field was
[ThinLTO] Fix empty .llvmcmd sections
When passing -lto-embed-bitcode=post-merge-pre-opt, we were getting empty .llvmcmd sections. It turns out that is because the CodeGenOptions::CmdArgs field was only populated when clang saw -fembed-bitcode={all|marker}.
This patch always populates the CodeGenOptions::CmdArgs. The overhead of carrying through in memory in all cases is likely negligible in the grand schema of things, and it keeps the using code simple.
Differential Revision: https://reviews.llvm.org/D90366
show more ...
|
#
57cdc52c |
| 22-Oct-2020 |
Venkataramanan Kumar <venkataramanan.kumar.llvm@gmail.com> |
Initial support for vectorization using Libmvec (GLIBC vector math library)
Differential Revision: https://reviews.llvm.org/D88154
|
#
7c3fea77 |
| 22-Oct-2020 |
Xiang1 Zhang <xiang1.zhang@intel.com> |
[X86] Support customizing stack protector guard
Reviewed By: nickdesaulniers, MaskRay
Differential Revision: https://reviews.llvm.org/D88631
|
#
2484e915 |
| 20-Oct-2020 |
Fangrui Song <i@maskray.me> |
[Driver] Clean up -gz & --compress-debug-sections
* Make cc1 and cc1as --compress-debug-sections an alias for --compress-debug-sections=zlib * Make -gz an alias for -gz=zlib
The new behavior is con
[Driver] Clean up -gz & --compress-debug-sections
* Make cc1 and cc1as --compress-debug-sections an alias for --compress-debug-sections=zlib * Make -gz an alias for -gz=zlib
The new behavior is consistent with GCC when binutils>=2.26 is detected: -gz is translated to --compress-debug-sections=zlib instead of --compress-debug-sections.
show more ...
|
#
545c687c |
| 20-Oct-2020 |
Fangrui Song <i@maskray.me> |
[gcov] Unify driver and CC1 option names for -ftest-coverage & -fprofile-arcs
No need to use -femit-coverage-notes and -femit-coverage-data.
|
#
0ab222e7 |
| 20-Oct-2020 |
Fangrui Song <i@maskray.me> |
[gcov] Delete CC1 option -test-coverage
The name is unfortunate because it is similar to the driver option -ftest-coverage. It turns out aside from one occurrence in a test, this option is not used.
|
#
774ab601 |
| 20-Oct-2020 |
Douglas Yung <douglas.yung@sony.com> |
Add option to use older clang ABI behavior when passing certain union types as function arguments
Recently commit D78699 (commit 26cfb6e562f1), fixed clang's behavior with respect to passing a union
Add option to use older clang ABI behavior when passing certain union types as function arguments
Recently commit D78699 (commit 26cfb6e562f1), fixed clang's behavior with respect to passing a union type through a register to correctly follow the ABI. However, this is an ABI breaking change with earlier versions of the clang compiler, so we should add an -fclang-abi-compat option to address this. Additionally, the PS4 ABI requires the older behavior, so that is added as well.
This change adds a Ver11 value to the ClangABI enum that when it is set (or the target is the PS4 triple), we skip the ABI fix introduced in D78699.
Differential Revision: https://reviews.llvm.org/D89747
show more ...
|