[Clang][CodeGen] fix failed assertion

Ensure we can emit symbol aliases via function attribute
even when function signatures contain incomplete types.

Via bugreport:
https://reviews.llvm.org/D66492

[Clang][CodeGen] fix failed assertion

Ensure we can emit symbol aliases via function attribute
even when function signatures contain incomplete types.

Via bugreport:
https://reviews.llvm.org/D66492#2350947

Reviewed By: erichkeane

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

show more ...

[Annotation] Allows annotation to carry some additional constant arguments.

This allows using annotation in a much more contexts than it currently has.
especially when annotation with template or co

[Annotation] Allows annotation to carry some additional constant arguments.

This allows using annotation in a much more contexts than it currently has.
especially when annotation with template or constexpr.

Reviewed By: aaron.ballman

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

show more ...

[clang] Enable support for #pragma STDC FENV_ACCESS

Reviewers: rjmccall, rsmith, sepavloff

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

[IR] add fn attr for no_stack_protector; prevent inlining on mismatch

It's currently ambiguous in IR whether the source language explicitly
did not want a stack a stack protector (in C, via function

[IR] add fn attr for no_stack_protector; prevent inlining on mismatch

It's currently ambiguous in IR whether the source language explicitly
did not want a stack a stack protector (in C, via function attribute
no_stack_protector) or doesn't care for any given function.

It's common for code that manipulates the stack via inline assembly or
that has to set up its own stack canary (such as the Linux kernel) would
like to avoid stack protectors in certain functions. In this case, we've
been bitten by numerous bugs where a callee with a stack protector is
inlined into an __attribute__((__no_stack_protector__)) caller, which
generally breaks the caller's assumptions about not having a stack
protector. LTO exacerbates the issue.

While developers can avoid this by putting all no_stack_protector
functions in one translation unit together and compiling those with
-fno-stack-protector, it's generally not very ergonomic or as
ergonomic as a function attribute, and still doesn't work for LTO. See also:
https://lore.kernel.org/linux-pm/[email protected]/
https://lore.kernel.org/lkml/[email protected]/T/#u

Typically, when inlining a callee into a caller, the caller will be
upgraded in its level of stack protection (see adjustCallerSSPLevel()).
By adding an explicit attribute in the IR when the function attribute is
used in the source language, we can now identify such cases and prevent
inlining. Block inlining when the callee and caller differ in the case that one
contains `nossp` when the other has `ssp`, `sspstrong`, or `sspreq`.

Fixes pr/47479.

Reviewed By: void

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

show more ...

[c++20] For P0732R2 / P1907R1: Basic frontend support for class types as
non-type template parameters.

Create a unique TemplateParamObjectDecl instance for each such value,
representing the globally

[c++20] For P0732R2 / P1907R1: Basic frontend support for class types as
non-type template parameters.

Create a unique TemplateParamObjectDecl instance for each such value,
representing the globally unique template parameter object to which the
template parameter refers.

No IR generation support yet; that will follow in a separate patch.

show more ...

Revert "[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting"

This broke Chromium's PGO build, it seems because hot-cold-splitting got turned
on unintentionally. See comment on the cod

Revert "[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting"

This broke Chromium's PGO build, it seems because hot-cold-splitting got turned
on unintentionally. See comment on the code review for repro etc.

> This patch adds -f[no-]split-cold-code CC1 options to clang. This allows
> the splitting pass to be toggled on/off. The current method of passing
> `-mllvm -hot-cold-split=true` to clang isn't ideal as it may not compose
> correctly (say, with `-O0` or `-Oz`).
>
> To implement the -fsplit-cold-code option, an attribute is applied to
> functions to indicate that they may be considered for splitting. This
> removes some complexity from the old/new PM pipeline builders, and
> behaves as expected when LTO is enabled.
>
> Co-authored by: Saleem Abdulrasool <[email protected]>
> Differential Revision: https://reviews.llvm.org/D57265
> Reviewed By: Aditya Kumar, Vedant Kumar
> Reviewers: Teresa Johnson, Aditya Kumar, Fedor Sergeev, Philip Pfaffe, Vedant Kumar

This reverts commit 273c299d5d649a0222fbde03c9a41e41913751b4.

show more ...

[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting

This patch adds -f[no-]split-cold-code CC1 options to clang. This allows
the splitting pass to be toggled on/off. The current metho

[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting

This patch adds -f[no-]split-cold-code CC1 options to clang. This allows
the splitting pass to be toggled on/off. The current method of passing
`-mllvm -hot-cold-split=true` to clang isn't ideal as it may not compose
correctly (say, with `-O0` or `-Oz`).

To implement the -fsplit-cold-code option, an attribute is applied to
functions to indicate that they may be considered for splitting. This
removes some complexity from the old/new PM pipeline builders, and
behaves as expected when LTO is enabled.

Co-authored by: Saleem Abdulrasool <[email protected]>
Differential Revision: https://reviews.llvm.org/D57265
Reviewed By: Aditya Kumar, Vedant Kumar
Reviewers: Teresa Johnson, Aditya Kumar, Fedor Sergeev, Philip Pfaffe, Vedant Kumar

show more ...

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 ...

[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 ...

[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 ...

[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 ...

[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 ...

Fix a -Wparenthesis warning in 8ff44e644bb7, NFC

[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 ...

[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 ...

[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 ...

[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 ...

[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 ...

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

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <[email protected]>

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 <[email protected]>

Resubmit after breaking Windows and OSX builds.

Reviewed By: dblaikie

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

show more ...

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

This reverts commit e486921fd6cf96ae9114adac455f7c0b5c1088a7.

Breaks windows builds and osx builds.

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

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <[email protected]>

Reviewed By: dblaikie

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

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

Fixes pr/11710.
Signed-off-by: Nick Desaulniers <[email protected]>

Reviewed By: dblaikie

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

show more ...

[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 ...

[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 ...

[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 ...

[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 ...