History log of /llvm-project/clang/lib/CodeGen/CodeGenModule.cpp (Results 526 – 550 of 2157)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 79829a47 15-Oct-2020 Leonard Chan <leonardchan@google.com>

Revert "[clang] Add -fc++-abi= flag for specifying which C++ ABI to use"

This reverts commits 683b308c07bf827255fe1403056413f790e03729 and
8487bfd4e9ae186f9f588ef989d27a96cc2438c9.

We will go for a

Revert "[clang] Add -fc++-abi= flag for specifying which C++ ABI to use"

This reverts commits 683b308c07bf827255fe1403056413f790e03729 and
8487bfd4e9ae186f9f588ef989d27a96cc2438c9.

We will go for a more restricted approach that does not give freedom to
everyone to change ABIs on whichever platform.

See the discussion on https://reviews.llvm.org/D85802.

show more ...


# 683b308c 12-Aug-2020 Leonard Chan <leonardchan@google.com>

[clang] Add -fc++-abi= flag for specifying which C++ ABI to use

This implements the flag proposed in RFC http://lists.llvm.org/pipermail/cfe-dev/2020-August/066437.html.

The goal is to add a way to

[clang] Add -fc++-abi= flag for specifying which C++ ABI to use

This implements the flag proposed in RFC http://lists.llvm.org/pipermail/cfe-dev/2020-August/066437.html.

The goal is to add a way to override the default target C++ ABI through
a compiler flag. This makes it easier to test and transition between different
C++ ABIs through compile flags rather than build flags.

In this patch:
- Store `-fc++-abi=` in a LangOpt. This isn't stored in a
CodeGenOpt because there are instances outside of codegen where Clang
needs to know what the ABI is (particularly through
ASTContext::createCXXABI), and we should be able to override the
target default if the flag is provided at that point.
- Expose the existing ABIs in TargetCXXABI as values that can be passed
through this flag.
- Create a .def file for these ABIs to make it easier to check flag
values.
- Add an error for diagnosing bad ABI flag values.

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

show more ...


# a2cc8833 03-Oct-2020 Fangrui Song <i@maskray.me>

[CUDA] Don't call __cudaRegisterVariable on C++17 inline variables

D17779: host-side shadow variables of external declarations of device-side
global variables have internal linkage and are reference

[CUDA] Don't call __cudaRegisterVariable on C++17 inline variables

D17779: host-side shadow variables of external declarations of device-side
global variables have internal linkage and are referenced by
`__cuda_register_globals`.

nvcc from CUDA 11 does not allow `__device__ inline` or `__device__ constexpr`
(C++17 inline variables) but clang has incorrectly supported them for a while:

```
error: A __device__ variable cannot be marked constexpr
error: An inline __device__/__constant__/__managed__ variable must have internal linkage when the program is compiled in whole program mode (-rdc=false)
```

If such a variable (which has a comdat group) is discarded (a copy from another
translation unit is prevailing and selected), accessing the variable from
outside the section group (`__cuda_register_globals`) is a violation of the ELF
specification and will be rejected by linkers:

> A symbol table entry with STB_LOCAL binding that is defined relative to one of a group's sections, and that is contained in a symbol table section that is not part of the group, must be discarded if the group members are discarded. References to this symbol table entry from outside the group are not allowed.

As a workaround, don't register such inline variables for now.
(If we register the variables in all TUs, we will keep multiple instances of the shadow and break the C++ semantics for inline variables).
We should reject such variables in Sema but our internal users need some time to migrate.

Reviewed By: tra

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

show more ...


# a88c722e 25-Sep-2020 Momchil Velikov <momchil.velikov@arm.com>

[AArch64] PAC/BTI code generation for LLVM generated functions

PAC/BTI-related codegen in the AArch64 backend is controlled by a set
of LLVM IR function attributes, added to the function by Clang, b

[AArch64] PAC/BTI code generation for LLVM generated functions

PAC/BTI-related codegen in the AArch64 backend is controlled by a set
of LLVM IR function attributes, added to the function by Clang, based
on command-line options and GCC-style function attributes. However,
functions, generated in the LLVM middle end (for example,
asan.module.ctor or __llvm_gcov_write_out) do not get any attributes
and the backend incorrectly does not do any PAC/BTI code generation.

This patch record the default state of PAC/BTI codegen in a set of
LLVM IR module-level attributes, based on command-line options:

* "sign-return-address", with non-zero value means generate code to
sign return addresses (PAC-RET), zero value means disable PAC-RET.

* "sign-return-address-all", with non-zero value means enable PAC-RET
for all functions, zero value means enable PAC-RET only for
functions, which spill LR.

* "sign-return-address-with-bkey", with non-zero value means use B-key
for signing, zero value mean use A-key.

This set of attributes are always added for AArch64 targets (as
opposed, for example, to interpreting a missing attribute as having a
value 0) in order to be able to check for conflicts when combining
module attributed during LTO.

Module-level attributes are overridden by function level attributes.
All the decision making about whether to not to generate PAC and/or
BTI code is factored out into AArch64FunctionInfo, there shouldn't be
any places left, other than AArch64FunctionInfo, which directly
examine PAC/BTI attributes, except AArch64AsmPrinter.cpp, which
is/will-be handled by a separate patch.

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

show more ...


# 301e2330 22-Sep-2020 Yaxun (Sam) Liu <yaxun.liu@amd.com>

[CUDA][HIP] Fix static device var used by host code only

A static device variable may be accessed in host code through
cudaMemCpyFromSymbol etc. Currently clang does not
emit the static device varia

[CUDA][HIP] Fix static device var used by host code only

A static device variable may be accessed in host code through
cudaMemCpyFromSymbol etc. Currently clang does not
emit the static device variable if it is only referenced by
host code, which causes host code to fail at run time.

This patch fixes that.

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

show more ...


# 2d11ae0a 02-Sep-2020 Erik Pilkington <erik.pilkington@gmail.com>

Fix a -Wparenthesis warning in 8ff44e644bb7, NFC


# 8ff44e64 01-Sep-2020 Erik Pilkington <erik.pilkington@gmail.com>

[IRGen] Fix an assert when __attribute__((used)) is used on an ObjC method

This assert doesn't really make sense for functions in general, since they
start life as declarations, and there isn't real

[IRGen] Fix an assert when __attribute__((used)) is used on an ObjC method

This assert doesn't really make sense for functions in general, since they
start life as declarations, and there isn't really any reason to require them
to be defined before attributes are applied to them.

rdar://67895846

show more ...


# 17ceda99 27-Aug-2020 Craig Topper <craig.topper@intel.com>

[CodeGen] Use an AttrBuilder to bulk remove 'target-cpu', 'target-features', and 'tune-cpu' before re-adding in CodeGenModule::setNonAliasAttributes.

I think the removeAttributes interface should be

[CodeGen] Use an AttrBuilder to bulk remove 'target-cpu', 'target-features', and 'tune-cpu' before re-adding in CodeGenModule::setNonAliasAttributes.

I think the removeAttributes interface should be faster than
calling removeAttribute 3 times.

show more ...


# 724f570a 19-Aug-2020 Craig Topper <craig.topper@intel.com>

[X86] Add support 'tune' in target attribute

This adds parsing and codegen support for tune in target attribute.

I've implemented this so that arch in the target attribute implicitly disables tune

[X86] Add support 'tune' in target attribute

This adds parsing and codegen support for tune in target attribute.

I've implemented this so that arch in the target attribute implicitly disables tune from the command line. I'm not sure what gcc does here. But since -march implies -mtune. I assume 'arch' in the target attribute implies tune in the target attribute.

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

show more ...


# 4cbceb74 18-Aug-2020 Craig Topper <craig.topper@intel.com>

[X86] Add basic support for -mtune command line option in clang

Building on the backend support from D85165. This parses the command line option in the driver, passes it on to CC1 and adds a functio

[X86] Add basic support for -mtune command line option in clang

Building on the backend support from D85165. This parses the command line option in the driver, passes it on to CC1 and adds a function attribute.

-Still need to support tune on the target attribute.
-Need to use "generic" as the tuning by default. But need to change generic in the backend first.
-Need to set tune if march is specified and mtune isn't.
-May need to disable getHostCPUName's ability to guess CPU name from features when it doesn't have a family/model match for mtune=native. That's what gcc appears to do.

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

show more ...


# b3aece05 19-Jun-2020 Kai Nacke <kai.nacke@de.ibm.com>

[SystemZ/ZOS] Add binary format goff and operating system zos to the triple

Adds the binary format goff and the operating system zos to the triple
class. goff is selected as default binary format if

[SystemZ/ZOS] Add binary format goff and operating system zos to the triple

Adds the binary format goff and the operating system zos to the triple
class. goff is selected as default binary format if zos is choosen as
operating system. No further functionality is added.

Reviewers: efriedma, tahonermann, hubert.reinterpertcast, MaskRay

Reviewed By: efriedma, tahonermann, hubert.reinterpertcast

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

show more ...


# 4f2ad15d 10-Aug-2020 Nick Desaulniers <ndesaulniers@google.com>

[Clang] implement -fno-eliminate-unused-debug-types

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Resubmit after breaking Windows and OSX builds.

Reviewed By: dblaikie

[Clang] implement -fno-eliminate-unused-debug-types

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Resubmit after breaking Windows and OSX builds.

Reviewed By: dblaikie

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

show more ...


# abb9bf4b 07-Aug-2020 Nick Desaulniers <ndesaulniers@google.com>

Revert "[Clang] implement -fno-eliminate-unused-debug-types"

This reverts commit e486921fd6cf96ae9114adac455f7c0b5c1088a7.

Breaks windows builds and osx builds.


# e486921f 07-Aug-2020 Nick Desaulniers <ndesaulniers@google.com>

[Clang] implement -fno-eliminate-unused-debug-types

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Reviewed By: dblaikie

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

[Clang] implement -fno-eliminate-unused-debug-types

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Reviewed By: dblaikie

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

show more ...


# 160ff837 03-Aug-2020 Saiyedul Islam <Saiyedul.Islam@amd.com>

[OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 3

Provides AMDGCN and NVPTX specific specialization of getGPUWarpSize,
getGPUThreadID, and getGPUNumThreads methods. Adds te

[OpenMP][AMDGCN] Support OpenMP offloading for AMDGCN architecture - Part 3

Provides AMDGCN and NVPTX specific specialization of getGPUWarpSize,
getGPUThreadID, and getGPUNumThreads methods. Adds tests for AMDGCN
codegen for these methods in generic and simd modes. Also changes the
precondition in InitTempAlloca to be slightly more permissive. Useful for
AMDGCN OpenMP codegen where allocas are created with a cast to an
address space.

Reviewed By: ABataev

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

show more ...


# 8d27be8d 29-Jul-2020 Alexey Bader <alexey.bader@intel.com>

[OpenCL] Add global_device and global_host address spaces

This patch introduces 2 new address spaces in OpenCL: global_device and global_host
which are a subset of a global address space, so the add

[OpenCL] Add global_device and global_host address spaces

This patch introduces 2 new address spaces in OpenCL: global_device and global_host
which are a subset of a global address space, so the address space scheme will be
looking like:

```
generic->global->host
->device
->private
->local
constant
```

Justification: USM allocations may be associated with both host and device memory. We
want to give users a way to tell the compiler the allocation type of a USM pointer for
optimization purposes. (Link to the Unified Shared Memory extension:
https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/USM/cl_intel_unified_shared_memory.asciidoc)

Before this patch USM pointer could be only in opencl_global
address space, hence a device backend can't tell if a particular pointer
points to host or device memory. On FPGAs at least we can generate more
efficient hardware code if the user tells us where the pointer can point -
being able to distinguish between these types of pointers at compile time
allows us to instantiate simpler load-store units to perform memory
transactions.

Patch by Dmitry Sidorov.

Reviewed By: Anastasia

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

show more ...


# ec6ada62 16-Jul-2020 Xiangling Liao <Xiangling.Liao@ibm.com>

[AIX] report_fatal_error on `-fregister_global_dtors_with_atexit` for static init

On AIX, the semantic of global_dtors contains __sterm functions associated with C++
cleanup actions and user-declare

[AIX] report_fatal_error on `-fregister_global_dtors_with_atexit` for static init

On AIX, the semantic of global_dtors contains __sterm functions associated with C++
cleanup actions and user-declared __attribute__((destructor)) functions. We should
never merely register __sterm with atexit(), so currently
-fregister_global_dtors_with_atexit does not work well on AIX: It would cause
finalization actions to not occur when unloading shared libraries. We need to figure
out a way to handle that when we start supporting user-declared
__attribute__((destructor)) functions.

Currently we report_fatal_error on this option temporarily.

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

show more ...


# 6aab27ba 05-Jul-2020 sstefan1 <sstipanovic@s-energize.com>

[OpenMPIRBuilder][Fix] Move llvm::omp::types to OpenMPIRBuilder.

Summary:
D82193 exposed a problem with global type definitions in
`OMPConstants.h`. This causes a race when running in thinLTO mode.

[OpenMPIRBuilder][Fix] Move llvm::omp::types to OpenMPIRBuilder.

Summary:
D82193 exposed a problem with global type definitions in
`OMPConstants.h`. This causes a race when running in thinLTO mode.
Types now live inside of OpenMPIRBuilder to prevent this from happening.

Reviewers: jdoerfert

Subscribers: yaxunl, hiraditya, guansong, dexonsmith, aaron.ballman, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...


# dc3f8913 24-Jun-2020 Nigel Perks <nigelp@xmos.com>

Fix crash on XCore on unused inline in EmitTargetMetadata

EmitTargetMetadata passed to emitTargetMD a null pointer as returned
from GetGlobalValue, for an unused inline function which has been
remov

Fix crash on XCore on unused inline in EmitTargetMetadata

EmitTargetMetadata passed to emitTargetMD a null pointer as returned
from GetGlobalValue, for an unused inline function which has been
removed from the module at that point.

A FIXME in CodeGenModule.cpp commented that the calling code in
EmitTargetMetadata should be moved into the one target that needs it
(XCore). A review comment agreed. So the calling loop has been moved
into the XCore subclass. The check for null is done in that loop.

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

show more ...


# ebc9e0f1 24-Jun-2020 Michael Liao <michael.hliao@gmail.com>

Fix coding style. NFC.

- Remove `else` after `return`.


# bf8b63ed 28-Apr-2020 Eli Friedman <efriedma@quicinc.com>

[clang codegen] Fix alignment of "Address" for incomplete array pointer.

The code was assuming all incomplete types don't have meaningful
alignment, but incomplete arrays do have meaningful alignmen

[clang codegen] Fix alignment of "Address" for incomplete array pointer.

The code was assuming all incomplete types don't have meaningful
alignment, but incomplete arrays do have meaningful alignment.

Fixes https://bugs.llvm.org/show_bug.cgi?id=45710

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

show more ...


# 22337bfe 27-May-2020 Xiangling Liao <Xiangling.Liao@ibm.com>

[AIX][Frontend] Static init implementation for AIX considering no priority

1. Provides no piroirity supoort && disables three priority related
attributes: init_priority, ctor attr, dtor attr;
2.

[AIX][Frontend] Static init implementation for AIX considering no priority

1. Provides no piroirity supoort && disables three priority related
attributes: init_priority, ctor attr, dtor attr;
2. '-qunique' in XL compiler equivalent behavior of emitting sinit
and sterm functions name using getUniqueModuleId() util function
in LLVM (currently no support for InternalLinkage and WeakODRLinkage
symbols);
3. Add testcases to emit IR sample with __sinit80000000, __dtor, and
__sterm80000000;
4. Temporarily side-steps the need to implement the functionality of
llvm.global_ctors and llvm.global_dtors arrays. The uses of that
functionality in this patch (with respect to the name of the functions
involved) are not representative of how the functionality will be used
once implemented.

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

show more ...


# 4a177697 16-Jun-2020 Jun Ma <JunMa@linux.alibaba.com>

[CodeGen][TLS] Set TLS Model for __tls_guard as well.

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


# 51e4aa87 14-Jun-2020 Tyker <tyker1@outlook.com>

attempt to fix failing buildbots after 3bab88b7baa20b276faaee0aa7ca87f636c91877

Prevent IR-gen from emitting consteval declarations

Summary: with this patch instead of emitting calls to consteval f

attempt to fix failing buildbots after 3bab88b7baa20b276faaee0aa7ca87f636c91877

Prevent IR-gen from emitting consteval declarations

Summary: with this patch instead of emitting calls to consteval function. the IR-gen will emit a store of the already computed result.

show more ...


# 550c4562 15-Jun-2020 Kirill Bobyrev <kbobyrev@google.com>

Revert "Prevent IR-gen from emitting consteval declarations"

This reverts commit 3bab88b7baa20b276faaee0aa7ca87f636c91877.

This patch causes test failures:
http://lab.llvm.org:8011/builders/clang-c

Revert "Prevent IR-gen from emitting consteval declarations"

This reverts commit 3bab88b7baa20b276faaee0aa7ca87f636c91877.

This patch causes test failures:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/17260

show more ...


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