summaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenModule.cpp
AgeCommit message (Collapse)Author
2025-01-20[Clang][MIPS] Create correct linker arguments for Windows toolchains (#121041)Hervé Poussineau
2025-01-10[FMV][AArch64] Changes in fmv-features metadata. (#122192)Alexandros Lamprineas
* We want the default version to have this attribute too otherwise it becomes indistinguishable from non-versioned functions. * We don't need the '+' unlike target-features which can negate. This will allow using the parsing API of target_version/clones for the metadata too.
2025-01-08[FMV][AArch64] Simplify version selection according to ACLE. (#121921)Alexandros Lamprineas
Currently, the more features a version has, the higher its priority is. We are changing ACLE https://github.com/ARM-software/acle/pull/370 as follows: "Among any two versions, the higher priority version is determined by identifying the highest priority feature that is specified in exactly one of the versions, and selecting that version."
2025-01-07[FMV][AArch64][clang] Emit fmv-features metadata in LLVM IR. (#118544)Alexandros Lamprineas
We need to be able to propagate information about FMV attribute strings from C/C++ source to LLVM IR. This is necessary so that we can distinguish which target-features are coming from the cmdline, which are coming from the target attribute, and which are coming from feature dependency expansion. We need this for static resolution of calls in LLVM. Here's a motivating example: Suppose you have target_version("i8mm+dotprod") and target_version("fcma"). The first version clearly has higher priority. Now suppose you specify -march=armv8-a+i8mm on the command line. Then the versions would have target-features "+i8mm,+dotprod" and "+i8mm,+fcma" respectively. If you are using those to deduce version priority, then you would incorrectly deduce that the second version was higher priority than the first.
2024-12-19[FMV][AArch64] Emit mangled default version if explicitly specified. (#120022)Alexandros Lamprineas
Currently we need at least one more version other than the default to trigger FMV. However we would like a header file declaration __attribute__((target_version("default"))) void f(void); to guarantee that there will be f.default
2024-12-17[TySan] Add initial Type Sanitizer support to Clang) (#76260)Florian Hahn
This patch introduces the Clang components of type sanitizer: a sanitizer for type-based aliasing violations. It is based on Hal Finkel's https://reviews.llvm.org/D32198. The Clang changes are mostly formulaic, the one specific change being that when the TBAA sanitizer is enabled, TBAA is always generated, even at -O0. It goes together with the corresponding LLVM changes (https://github.com/llvm/llvm-project/pull/76259) and compiler-rt changes (https://github.com/llvm/llvm-project/pull/76261) PR: https://github.com/llvm/llvm-project/pull/76260
2024-12-16[PAC][ELF][AArch64] Support signed personality function pointer (#119361)Daniil Kovalev
Re-apply #113148 after revert in #119331 If function pointer signing is enabled, sign personality function pointer stored in `.DW.ref.__gxx_personality_v0` section with IA key, 0x7EAD = `ptrauth_string_discriminator("personality")` constant discriminator and address diversity enabled.
2024-12-10Revert "[PAC][ELF][AArch64] Support signed personality function pointer" ↵Daniil Kovalev
(#119331) Reverts llvm/llvm-project#113148 See buildbot failure https://lab.llvm.org/buildbot/#/builders/190/builds/11048
2024-12-10[PAC][ELF][AArch64] Support signed personality function pointer (#113148)Daniil Kovalev
If function pointer signing is enabled, sign personality function pointer stored in `.DW.ref.__gxx_personality_v0` section with IA key, 0x7EAD = `ptrauth_string_discriminator("personality")` constant discriminator and address diversity enabled.
2024-12-02[Clang] ensure mangled names are valid identifiers before being suggested in ↵Oleksandr T.
ifunc/alias attributes notes (#118170) Fixes #112205 --- Commit that introduced this feature - https://github.com/llvm/llvm-project/commit/9306ef9750b7a319d59f6d3e4977e01e39b8f161
2024-11-28[NFC][clang][FMV][TargetInfo] Refactor API for FMV feature priority. (#116257)Alexandros Lamprineas
Currently we have code with target hooks in CodeGenModule shared between X86 and AArch64 for sorting MultiVersionResolverOptions. Those are used when generating IFunc resolvers for FMV. The RISCV target has different criteria for sorting, therefore it repeats sorting after calling CodeGenFunction::EmitMultiVersionResolver. I am moving the FMV priority logic in TargetInfo, so that it can be implemented by the TargetParser which then makes it possible to query it from llvm. Here is an example why this is handy: https://github.com/llvm/llvm-project/pull/87939
2024-11-26[clang][FMV] Fix crash with cpu_specific attribute. (#115762)Alexandros Lamprineas
When dealing with cpu_specific GlobalDecl, GetOrCreateMultiVersionResolver should immediately return the already created llvm function if it exists. Fixes https://github.com/llvm/llvm-project/issues/115299.
2024-11-25[clang][codegen] Mention the invariant that LLVM demangler should be … ↵Viktoriia Bakalova
(#117346) …able to handle mangled names generated by clang. https://discourse.llvm.org/t/rfc-clang-diagnostic-for-demangling-failures/82835/8 Since we're putting the work on the above RFC on hold, let's leave a comment in the source code pointing to prior efforts and the suggestion of further steps.
2024-11-19[clang] Change some placeholders from undef to poison [NFC]Nuno Lopes
2024-11-19[PAC][clang] Add signed GOT cc1 flag (#96160)Daniil Kovalev
Add `-fptrauth-elf-got` clang cc1 flag and set `ptrauth_elf_got` preprocessor feature and `PointerAuthELFGOT` LangOption correspondingly. No additional checks like ensuring OS binary format is ELF are performed: it should be done on clang driver level when a pauth-enabled environment implying signed GOT enabled is requested. If the cc1 flag is passed, "ptrauth-elf-got" IR module flag is set.
2024-11-16[CodeGen] Remove unused includes (NFC) (#116459)Kazu Hirata
Identified with misc-include-cleaner.
2024-11-14[clang codegen] Add CreateRuntimeFunction overload that takes a clang type. ↵Eli Friedman
(#113506) Correctly computing the LLVM types/attributes is complicated in general, so add a variant which does that for you.
2024-10-30[C++20] [Modules] Fix the duplicated static initializer problem (#114193)Chuanqi Xu
Reproducer: ``` //--- a.cppm export module a; int func(); static int a = func(); //--- a.cpp import a; ``` The `func()` should only execute once. However, before this patch we will somehow import `static int a` from a.cppm incorrectly and initialize that again. This is super bad and can introduce serious runtime behaviors. And also surprisingly, it looks like the root cause of the problem is simply some oversight choosing APIs.
2024-10-23[clang codegen] avoid to crash when emit init func for global variable with ↵Congcong Cai
flexible array init (#113336) Fixes: #113187 Avoid to create init function since clang does not support global variable with flexible array init. It will cause assertion failure later.
2024-10-18[clang] Deduplicate the logic that only warns once when stack is almost full ↵Boaz Brickner
(#112552) Zero diff in behavior.
2024-10-17[HLSL] Add handle initialization for simple resource declarations (#111207)Helena Kotas
Adds `@_init_resource_bindings()` function to module initialization that includes `handle.fromBinding` intrinsic calls for simple resource declarations. Arrays of resources or resources inside user defined types are not supported yet. While this unblocks our progress on [Compile a runnable shader from clang](https://github.com/llvm/wg-hlsl/issues/7) milestone, this is probably not the way we would like to handle resource binding initialization going forward. Ideally, it should be done via the resource class constructors in order to support dynamic resource binding or unbounded arrays if resources. Depends on PRs #110327 and #111203. Part 1 of #105076
2024-10-16[HLSL][SPIRV] Use Spirv target codegen (#112573)Steven Perron
When the arch in the triple in "spirv", the default target codegen is currently used. We should be using the spir-v target codegen. This will be used to have SPIR-V specific lowering of the HLSL types.
2024-10-14[clang] Fix segmentation fault caused by stack overflow on deeply nested ↵Boaz Brickner
expressions (#111701) Done by calling clang::runWithSufficientStackSpace(). Added CodeGenModule::runWithSufficientStackSpace() method similar to the one in Sema to provide a single warning when this triggers Fixes: #111699
2024-10-14[LLVM] [Clang] Support for Gentoo `*t64` triples (64-bit time_t ABIs) (#111302)Michał Górny
Gentoo is planning to introduce a `*t64` suffix for triples that will be used by 32-bit platforms that use 64-bit `time_t`. Add support for parsing and accepting these triples, and while at it make clang automatically enable the necessary glibc feature macros when this suffix is used. An open question is whether we can backport this to LLVM 19.x. After all, adding new triplets to Triple sounds like an ABI change — though I suppose we can minimize the risk of breaking something if we move new enum values to the very end.
2024-10-11[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)Rahul Joshi
Rename the function to reflect its correct behavior and to be consistent with `Module::getOrInsertFunction`. This is also in preparation of adding a new `Intrinsic::getDeclaration` that will have behavior similar to `Module::getFunction` (i.e, just lookup, no creation).
2024-10-08Recommit "[RISCV][FMV] Support target_version" (#111096)" (#111333)Piyou Chen
Fix the buildbot failure caused by heap use-after-free error. Origin message: This patch enable `target_version` attribute for RISC-V target. The proposal of `target_version` syntax can be found at the https://github.com/riscv-non-isa/riscv-c-api-doc/pull/48 (which has landed), as modified by the proposed https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85 (which adds the priority syntax). `target_version` attribute will trigger the function multi-versioning feature and act like `target_clones` attribute. See https://github.com/llvm/llvm-project/pull/85786 for the implementation of `target_clones`.
2024-10-04Revert "[RISCV][FMV] Support target_version" (#111096)Piyou Chen
Reverts llvm/llvm-project#99040 due to https://lab.llvm.org/buildbot/#/builders/190/builds/7052
2024-10-04[RISCV][FMV] Support target_version (#99040)Piyou Chen
This patch enable `target_version` attribute for RISC-V target. The proposal of `target_version` syntax can be found at the https://github.com/riscv-non-isa/riscv-c-api-doc/pull/48 (which has landed), as modified by the proposed https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85 (which adds the priority syntax). `target_version` attribute will trigger the function multi-versioning feature and act like `target_clones` attribute. See https://github.com/llvm/llvm-project/pull/85786 for the implementation of `target_clones`.
2024-09-29[cuda][HIP] `__constant__` should imply constant (#110182)Alex Voicu
Currently, `__constant__` variables do not get unconditionally marked as `constant` in IR, which seems a bit odd given their definition. This is generally inconsequential for NVPTX/AMDGPU, since said variables get emitted in the constant address space for those BEs. However, it is potentially significant for e.g. HIP-on-SPIR-V cases, as SPIR-V does not allow casts to/from the constant AS (`UniformConstant`), which forces `__constant__` variables to be emitted in the global AS, thus making IR constness meaningful.
2024-09-26[clang][RISCV] Introduce command line options for RISC-V Zicfilp CFIMing-Yi Lai
This patch enables the following command line flags for RISC-V targets: + `-fcf-protection=branch` turns on forward-edge control-flow integrity conditioning + `-mcf-branch-label-scheme=unlabeled|func-sig` selects the label scheme used in the forward-edge CFI conditioning
2024-09-24[codegen][NFC] add static mark for internal usage variable and function ↵Congcong Cai
(#109431) Detect by clang-tidy misc-use-internal-linkage
2024-09-17Reapply "[HLSL] set alwaysinline on HLSL functions (#106588)"Thurston Dang
This reverts commit 4a63f4d301c0e044073e1b1f8f110015ec1778a1. It was reverted because of a buildbot breakage, but the fix-forward has landed (https://github.com/llvm/llvm-project/pull/109023).
2024-09-17Revert "[HLSL] set alwaysinline on HLSL functions (#106588)"Thurston Dang
This reverts commit a729e706de3fc6ebee49ede3c50afb47f2e29191. Reason:bBuildbot failure (https://lab.llvm.org/buildbot/#/builders/25/builds/2541): 'Clang :: CodeGenHLSL/builtins/StructuredBuffer-subscript.hlsl' failed
2024-09-17[HLSL] set alwaysinline on HLSL functions (#106588)Greg Roth
HLSL inlines all its functions by default. This uses the alwaysinline attribute to make the alwaysinliner pass inline any function not explicitly marked noinline by the user or autogeneration. The alwayslinline marking takes place in `SetLLVMFunctionAttributesForDefinitions` where all other inlining interactions are determined. The outermost entry function is marked noinline because there's no reason to inline it. Any user calls to an entry function will instead call the internal mangled version of the entry function. Adds tests for function and constructor inlining and augments some existing tests to verify correct inlining of implicitly created functions as well. Incidentally restore RUN line that I believe was mistakenly removed as part of #88918 Fixes #89282
2024-09-13[RISCV][FMV] Support target_clones (#85786)Piyou Chen
This patch enable the function multiversion(FMV) and `target_clones` attribute for RISC-V target. The proposal of `target_clones` syntax can be found at the https://github.com/riscv-non-isa/riscv-c-api-doc/pull/48 (which has landed), as modified by the proposed https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85 (which adds the priority syntax). It supports the `target_clones` function attribute and function multiversioning feature for RISC-V target. It will generate the ifunc resolver function for the function that declared with target_clones attribute. The resolver function will check the version support by runtime object `__riscv_feature_bits`. For example: ``` __attribute__((target_clones("default", "arch=+ver1", "arch=+ver2"))) int bar() { return 1; } ``` the corresponding resolver will be like: ``` bar.resolver() { __init_riscv_feature_bits(); // Check arch=+ver1 if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION1) == BITMASK_OF_VERSION1) { return bar.arch=+ver1; } else { // Check arch=+ver2 if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION2) == BITMASK_OF_VERSION2) { return bar.arch=+ver2; } else { // Default return bar.default; } } } ```
2024-09-10[DirectX] Add DirectXTargetCodeGenInfo (#104856)Helena Kotas
Adds target codegen info class for DirectX. For now it always translates `__hlsl_resource_t` handle to `target("dx.TypedBuffer", i32, 1, 0, 1)` (`RWBuffer<int>`). More work is needed to determine the actual target exp type and parameters based on the resource handle attributes. Part 1/2 of #95952
2024-08-28[CodeGen] Create IFUNCs in the program address space, not hard-coded 0 (#105726)Jessica Clarke
Commit 0d527e56a5ee ("GlobalIFunc: Make ifunc respect function address spaces") added support for this within LLVM, but Clang does not properly honour the target's address spaces when creating IFUNCs, crashing with RAUW and verifier assertion failures when compiling C code on a target with a non-zero program address space, so fix this.
2024-08-21[clang-repl] [codegen] Reduce the state in TBAA. NFC for static compilation. ↵Vassil Vassilev
(#98138) In incremental compilation clang works with multiple `llvm::Module`s. Our current approach is to create a CodeGenModule entity for every new module request (via StartModule). However, some of the state such as the mangle context needs to be preserved to keep the original semantics in the ever-growing TU. Fixes: llvm/llvm-project#95581. cc: @jeaye
2024-08-20Fix KCFI types for generated functions with integer normalization (#104826)Sami Tolvanen
With -fsanitize-cfi-icall-experimental-normalize-integers, Clang appends ".normalized" to KCFI types in CodeGenModule::CreateKCFITypeId, which changes type hashes also for functions that don't have integer types in their signatures. However, llvm::setKCFIType does not take integer normalization into account, which means LLVM generated functions with KCFI types, e.g. sanitizer constructors, will fail KCFI checks when integer normalization is enabled in Clang. Add a cfi-normalize-integers module flag to indicate integer normalization is used, and append ".normalized" to KCFI types also in llvm::setKCFIType to fix the type mismatch.
2024-08-19[PAC][ELF][AArch64] Encode several ptrauth features in PAuth core info (#102508)Daniil Kovalev
For llvm_linux platform, define the following meaning for bits 9, 10, 11: - bit 9: set if indirect gotos signing is enabled; - bit 10: set if type info vtable pointer discrimination is enabled; - bit 11: set if function pointer type discrimination is enabled.
2024-08-09[DebugInfo][RemoveDIs] Use iterator-inserters in clang (#102006)Jeremy Morse
As part of the LLVM effort to eliminate debug-info intrinsics, we're moving to a world where only iterators should be used to insert instructions. This isn't a problem in clang when instructions get generated before any debug-info is inserted, however we're planning on deprecating and removing the instruction-pointer insertion routines. Scatter some calls to getIterator in a few places, remove a deref-then-addrof on another iterator, and add an overload for the createLoadInstBefore utility. Some callers passes a null insertion point, which we need to handle explicitly now.
2024-08-06[PAC][ELF][AArch64] Encode signed GOT flag in PAuth core info (#96159)Daniil Kovalev
Treat 8th bit of version value for llvm_linux platform as signed GOT flag. - clang: define `PointerAuthELFGOT` LangOption and set 8th bit of `aarch64-elf-pauthabi-version` LLVM module flag correspondingly; - llvm-readobj: print `PointerAuthELFGOT` or `!PointerAuthELFGOT` in version description of llvm_linux platform depending on whether the flag is set.
2024-08-06Reapply "Finish deleting the le32/le64 targets" (#99079) (#101983)Aaron Ballman
This reverts commit d3f8105c65046173e20c4c59394b4a7f1bbe7627. Halide no longer relies on this target: https://github.com/llvm/llvm-project/pull/98497#issuecomment-2253358685
2024-08-06[PAC][AArch64] Support init/fini array signing (#96478)Daniil Kovalev
If both `-fptrauth-init-fini` and `-fptrauth-calls` are passed, sign function pointers in `llvm.global_ctors` and `llvm.global_dtors` with constant discriminator 0xD9D4 (`ptrauth_string_discriminator("init_fini")`). Additionally, if `-fptrauth-init-fini-address-discrimination` is passed, address discrimination is used for signing (otherwise, just constant discriminator is used). For address discrimination, we use it's special form since uses of `llvm.global_{c|d}tors` are disallowed (see `Verifier::visitGlobalVariable`) and we can't emit `getelementptr` expressions referencing these special arrays. A signed ctor/dtor pointer with special address discrimination applied looks like the following: ``` ptr ptrauth (ptr @foo, i32 0, i64 55764, ptr inttoptr (i64 1 to ptr)) ```
2024-08-01[C++20] [Modules] Always emit the inline builtins (#101278)Chuanqi Xu
See the attached test for the motivation example. If we're too greedy to not emit the definition for inline builtins, we may meet a middle end crash. And it should be good to emit inline builtins always.
2024-07-31[Clang] [NFC] Fix potential dereferencing of nullptr (#101405)smanna12
This patch replaces getAs with castAs and dyn_cast with cast to ensure type safety and prevents potential null pointer dereferences. These changes enforce compile-time checks for correct type casting in ASTContext and CodeGenModule.
2024-07-30Revert "[C++20] [Modules] Always emit the inline builtins"Haowei Wu
This reverts commit ca8a4111f796fe8533e0af95557875b15becff06. This patch broke clang test on Windows x64 msvc
2024-07-30[clang][OpenMP] Rename `varlists` to `varlist`, NFC (#101058)Krzysztof Parzyszek
It returns a range of variables (via Expr*), not a range of lists.
2024-07-30[C++20] [Modules] Always emit the inline builtinsChuanqi Xu
See the attached test for the motivation example. If we're too greedy to not emit the definition for inline builtins, we may meet a middle end crash. And it should be good to emit inline builtins always.
2024-07-22[PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (#97237)Daniil Kovalev
When `pauthtest` is either passed as environment part of AArch64 Linux triple or passed via `-mabi=`, enable the following ptrauth flags: - `intrinsics`; - `calls`; - `returns`; - `auth-traps`; - `vtable-pointer-address-discrimination`; - `vtable-pointer-type-discrimination`; - `init-fini`. Some related stuff is still subject to change, and the ABI itself might be changed, so end users are not expected to use this and the ABI name has 'test' suffix. If `-mabi=pauthtest` option is used, it's normalized to effective triple. When the environment part of the effective triple is `pauthtest`, try to use `aarch64-linux-pauthtest` as multilib directory. The following is not supported: - combination of `pauthtest` ABI with any branch protection scheme except BTI; - explicit set of environment part of the triple to a value different from `pauthtest` in combination with `-mabi=pauthtest`; - usage on non-Linux OS. --------- Co-authored-by: Anatoly Trosinenko <atrosinenko@accesssoftek.com>