#
1408f91a |
| 26-Sep-2018 |
Kelvin Li <kkwli0@gmail.com> |
[OPENMP] Add support for OMP5 requires directive + unified_address clause
Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional
[OPENMP] Add support for OMP5 requires directive + unified_address clause
Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses.
Differential Revision: https://reviews.llvm.org/D52359
llvm-svn: 343063
show more ...
|
#
34e24d5b |
| 25-Sep-2018 |
Kristina Brooks <kristina@nym.hush.com> |
Reland "[Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with `-fconstant-cfstrings`"
Relanding rL342883 with more fragmented tests to test ELF-specific section emission separately from broad-scope
Reland "[Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with `-fconstant-cfstrings`"
Relanding rL342883 with more fragmented tests to test ELF-specific section emission separately from broad-scope CFString tests. Now this tests the following separately
1). CoreFoundation builds and linkage for ELF while building it. 2). CFString ELF section emission outside CF in assembly output. 3). Broad scope `cfstring3.c` tests which cover all object formats at bitcode level and assembly level (including ELF).
This fixes non-bridged CoreFoundation builds on ELF targets that use -fconstant-cfstrings. The original changes from differential for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not check for an edge case where the global could be a constant which surfaced as an issue when building for ELF because of different linkage semantics.
This patch addresses several issues with crashes related to CF builds on ELF as well as improves data layout by ensuring string literals that back the actual CFConstStrings end up in .rodata in line with Mach-O.
Change itself tested with CoreFoundation on Linux x86_64 but should be valid for BSD-like systems as well that use ELF as the native object format.
Differential Revision: https://reviews.llvm.org/D52344
llvm-svn: 343038
show more ...
|
#
a6398cdc |
| 24-Sep-2018 |
Kristina Brooks <kristina@nym.hush.com> |
Revert "rL342883: [Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with `-fconstant-cfstrings`."
Seems to be causing buildbot failures, need to look into it.
llvm-svn: 342893
|
#
7c142a52 |
| 24-Sep-2018 |
Kristina Brooks <kristina@nym.hush.com> |
[Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with `-fconstant-cfstrings`.
[Clang][CodeGen][ObjC]: Fix non-bridged CoreFoundation builds on ELF targets that use `-fconstant-cfstrings`. The origi
[Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with `-fconstant-cfstrings`.
[Clang][CodeGen][ObjC]: Fix non-bridged CoreFoundation builds on ELF targets that use `-fconstant-cfstrings`. The original changes from differential for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not check for an edge case where the global could be a constant which surfaced as an issue when building for ELF because of different linkage semantics.
This patch addresses several issues with crashes related to CF builds on ELF as well as improves data layout by ensuring string literals that back the actual CFConstStrings end up in .rodata in line with Mach-O.
Change itself tested with CoreFoundation on Linux x86_64 but should be valid for BSD-like systems as well that use ELF as the native object format.
Differential Revision: https://reviews.llvm.org/D52344
llvm-svn: 342883
show more ...
|
#
62279730 |
| 21-Sep-2018 |
Caroline Tice <cmtice@google.com> |
Add necessary support for storing code-model to module IR.
Currently the code-model does not get saved in the module IR, so if a code model is specified when compiling with LTO, it gets lost and is
Add necessary support for storing code-model to module IR.
Currently the code-model does not get saved in the module IR, so if a code model is specified when compiling with LTO, it gets lost and is not propagated properly to LTO. This patch does what is necessary in the front end to pass the code-model to the module, so that the back end can store it in the Module .
Differential Revision: https://reviews.llvm.org/D52323
llvm-svn: 342758
show more ...
|
#
05cf4434 |
| 14-Sep-2018 |
Dean Michael Berris <dberris@google.com> |
[XRay][clang] Emit "never-instrument" attribute
Summary: Before this change, we only emit the XRay attributes in LLVM IR when the -fxray-instrument flag is provided. This may cause issues with thinl
[XRay][clang] Emit "never-instrument" attribute
Summary: Before this change, we only emit the XRay attributes in LLVM IR when the -fxray-instrument flag is provided. This may cause issues with thinlto when the final binary is being built/linked with -fxray-instrument, and the constitutent LLVM IR gets re-lowered with xray instrumentation.
With this change, we can honour the "never-instrument "attributes provided in the source code and preserve those in the IR. This way, even in thinlto builds, we retain the attributes which say whether functions should never be XRay instrumented.
This change addresses llvm.org/PR38922.
Reviewers: mboerger, eizan
Subscribers: mehdi_amini, dexonsmith, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D52015
llvm-svn: 342200
show more ...
|
Revision tags: llvmorg-7.0.0 |
|
#
f353ae18 |
| 13-Sep-2018 |
Erich Keane <erich.keane@intel.com> |
[NFC]Refactor MultiVersion Resolver Emission to combine types
Previously, both types (plus the future target-clones) of multiversioning had a separate ResolverOption structure and emission function.
[NFC]Refactor MultiVersion Resolver Emission to combine types
Previously, both types (plus the future target-clones) of multiversioning had a separate ResolverOption structure and emission function. This patch combines the two, at the expense of a slightly more expensive sorting function.
llvm-svn: 342152
show more ...
|
#
be0c5b6d |
| 12-Sep-2018 |
David Green <david.green@arm.com> |
[CodeGen] Align rtti and vtable data
Previously the alignment on the newly created rtti/typeinfo data was largely not set, meaning that DataLayout::getPreferredAlignment was free to overalign it to
[CodeGen] Align rtti and vtable data
Previously the alignment on the newly created rtti/typeinfo data was largely not set, meaning that DataLayout::getPreferredAlignment was free to overalign it to 16 bytes. This causes unnecessary code bloat.
Differential Revision: https://reviews.llvm.org/D51416
llvm-svn: 342053
show more ...
|
Revision tags: llvmorg-7.0.0-rc3 |
|
#
7a368968 |
| 06-Sep-2018 |
Reid Kleckner <rnk@google.com> |
Re-land r334417 "[MS] Use mangled names and comdats for string merging with ASan"
The issue with -fprofile-generate was fixed and the dependent CL relanded in r340232.
llvm-svn: 341572
|
#
bd8ff9bd |
| 30-Aug-2018 |
Alexey Bataev <a.bataev@hotmail.com> |
[OPENMP] Fix PR38710: static functions are not emitted as implicitly 'declare target'.
All the functions, referenced in implicit|explicit target regions must be emitted during code emission for the
[OPENMP] Fix PR38710: static functions are not emitted as implicitly 'declare target'.
All the functions, referenced in implicit|explicit target regions must be emitted during code emission for the device.
llvm-svn: 341093
show more ...
|
#
5ff7a8e6 |
| 29-Aug-2018 |
Martin Storsjo <martin@martin.st> |
[MinGW] Don't mark external variables as DSO local
Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local
[MinGW] Don't mark external variables as DSO local
Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure.
Keep marking thread local variables as DSO local.
Differential Revision: https://reviews.llvm.org/D51382
llvm-svn: 340941
show more ...
|
#
6593df24 |
| 22-Aug-2018 |
Elizabeth Andrews <elizabeth.andrews@intel.com> |
Currently clang does not emit unused static constants. GCC emits these constants by default when there is no optimization.
GCC's option -fno-keep-static-consts can be used to not emit unused static
Currently clang does not emit unused static constants. GCC emits these constants by default when there is no optimization.
GCC's option -fno-keep-static-consts can be used to not emit unused static constants.
In Clang, since default behavior does not keep unused static constants, -fkeep-static-consts can be used to emit these if required. This could be useful for producing identification strings like SVN identifiers inside the object file even though the string isn't used by the program.
Differential Revision: https://reviews.llvm.org/D40925
llvm-svn: 340439
show more ...
|
Revision tags: llvmorg-7.0.0-rc2 |
|
#
7f792cab |
| 20-Aug-2018 |
Alexey Bataev <a.bataev@hotmail.com> |
[OPENMP] Fix crash on the emission of the weak function declaration.
If the function is actually a weak reference, it should not be marked as deferred definition as this is only a declaration. Patch
[OPENMP] Fix crash on the emission of the weak function declaration.
If the function is actually a weak reference, it should not be marked as deferred definition as this is only a declaration. Patch adds checks for the definitions if they must be emitted. Otherwise, only declaration is emitted.
llvm-svn: 340191
show more ...
|
#
d01b7497 |
| 15-Aug-2018 |
Alexey Bataev <a.bataev@hotmail.com> |
[OPENMP] FIx processing of declare target variables.
The compiler may produce unexpected error messages/crashes when declare target variables were used. Patch fixes problems with the declarations ma
[OPENMP] FIx processing of declare target variables.
The compiler may produce unexpected error messages/crashes when declare target variables were used. Patch fixes problems with the declarations marked as declare target to or link.
llvm-svn: 339805
show more ...
|
#
a912e3e6 |
| 10-Aug-2018 |
Hans Wennborg <hans@hanshq.net> |
clang-cl: Support /guard:cf,nochecks
This extension emits the guard cf table without inserting the instrumentation. Currently that's what clang-cl does with /guard:cf anyway, but this allows a user
clang-cl: Support /guard:cf,nochecks
This extension emits the guard cf table without inserting the instrumentation. Currently that's what clang-cl does with /guard:cf anyway, but this allows a user to request that explicitly.
Differential Revision: https://reviews.llvm.org/D50513
llvm-svn: 339420
show more ...
|
#
f2ceec48 |
| 09-Aug-2018 |
Stephen Kelly <steveire@gmail.com> |
Port getLocStart -> getBeginLoc
Reviewers: teemperor!
Subscribers: jholewinski, whisperity, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D50350
llvm-svn: 339385
|
#
bf8fe71b |
| 07-Aug-2018 |
Alexey Bataev <a.bataev@hotmail.com> |
[OPENMP] Mark variables captured in declare target region as implicitly declare target.
According to OpenMP 5.0, variables captured in lambdas in declare target regions must be considered as implici
[OPENMP] Mark variables captured in declare target region as implicitly declare target.
According to OpenMP 5.0, variables captured in lambdas in declare target regions must be considered as implicitly declare target.
llvm-svn: 339152
show more ...
|
Revision tags: llvmorg-7.0.0-rc1 |
|
#
6907ce2f |
| 30-Jul-2018 |
Fangrui Song <maskray@google.com> |
Remove trailing space
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338291
|
#
a4005e13 |
| 28-Jul-2018 |
Yaxun Liu <Yaxun.Liu@amd.com> |
[CUDA][HIP] Allow function-scope static const variable
CUDA 8.0 E.3.9.4 says: Within the body of a __device__ or __global__ function, only __shared__ variables or variables without any device memory
[CUDA][HIP] Allow function-scope static const variable
CUDA 8.0 E.3.9.4 says: Within the body of a __device__ or __global__ function, only __shared__ variables or variables without any device memory qualifiers may be declared with static storage class.
It is unclear how a function-scope non-const static variable without device memory qualifier is implemented, therefore only static const variable without device memory qualifier is allowed, which can be emitted as a global variable in constant address space.
Currently clang only allows function-scope static variable with __shared__ qualifier.
This patch also allows function-scope static const variable without device memory qualifier and emits it as a global variable in constant address space.
Differential Revision: https://reviews.llvm.org/D49931
llvm-svn: 338188
show more ...
|
#
e1bfbc58 |
| 21-Jul-2018 |
Yaxun Liu <Yaxun.Liu@amd.com> |
[HIP] Support -fcuda-flush-denormals-to-zero for amdgcn
Differential Revision: https://reviews.llvm.org/D48287
llvm-svn: 337639
|
#
3efe0020 |
| 20-Jul-2018 |
Erich Keane <erich.keane@intel.com> |
Implement cpu_dispatch/cpu_specific Multiversioning
As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is
Implement cpu_dispatch/cpu_specific Multiversioning
As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning.
This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions.
This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units.
The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions.
Differential Revision: https://reviews.llvm.org/D47474
llvm-svn: 337552
show more ...
|
#
7963e8be |
| 18-Jul-2018 |
Erich Keane <erich.keane@intel.com> |
Add support for __declspec(code_seg("segname"))
This patch uses CodeSegAttr to represent __declspec(code_seg) rather than building on the existing support for #pragma code_seg. The code_seg declspe
Add support for __declspec(code_seg("segname"))
This patch uses CodeSegAttr to represent __declspec(code_seg) rather than building on the existing support for #pragma code_seg. The code_seg declspec is applied on functions and classes. This attribute enables the placement of code into separate named segments, including compiler- generated codes and template instantiations.
For more information, please see the following: https://msdn.microsoft.com/en-us/library/dn636922.aspx
This patch fixes the regression for the support for attribute ((section). https://github.com/llvm-mirror/clang/commit/746b78de7812bc785fbb5207b788348040b23fa7
Patch by Soumi Manna (Manna) Differential Revision: https://reviews.llvm.org/D48841
llvm-svn: 337420
show more ...
|
#
a934f9da |
| 11-Jul-2018 |
Petr Pavlu <petr.pavlu@arm.com> |
Fix setting of empty implicit-section-name attribute
Code in `CodeGenModule::SetFunctionAttributes()` could set an empty attribute `implicit-section-name` on a function that is affected by `#pragma
Fix setting of empty implicit-section-name attribute
Code in `CodeGenModule::SetFunctionAttributes()` could set an empty attribute `implicit-section-name` on a function that is affected by `#pragma clang text="section"`. This is incorrect because the attribute should contain a valid section name. If the function additionally also used `__attribute__((section("section")))` then this could result in emitting the function in a section with an empty name.
The patch fixes the issue by removing the problematic code that sets empty `implicit-section-name` from `CodeGenModule::SetFunctionAttributes()` because it is sufficient to set this attribute only from a similar code in `setNonAliasAttributes()` when the function is emitted.
Differential Revision: https://reviews.llvm.org/D48916
llvm-svn: 336842
show more ...
|
#
c66d254d |
| 27-Jun-2018 |
Artem Belevich <tra@google.com> |
[CUDA] Use atexit() to call module destructor.
This matches the way NVCC does it. Doing module cleanup at global destructor phase used to work, but is, apparently, too late for the CUDA runtime in C
[CUDA] Use atexit() to call module destructor.
This matches the way NVCC does it. Doing module cleanup at global destructor phase used to work, but is, apparently, too late for the CUDA runtime in CUDA-9.2, which ends up crashing with double-free.
Differential Revision: https://reviews.llvm.org/D48613
llvm-svn: 335763
show more ...
|
#
c69e0676 |
| 26-Jun-2018 |
Evgeniy Stepanov <eugeni.stepanov@gmail.com> |
Revert "[MS] Use mangled names and comdats for string merging with ASan"
Depends on r334313, which has been reverted in r335681.
llvm-svn: 335684
|