History log of /llvm-project/clang/lib/CodeGen/CodeGenModule.cpp (Results 726 – 750 of 2157)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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


1...<<21222324252627282930>>...87