aboutsummaryrefslogtreecommitdiff
path: root/llvm/include/llvm/CodeGen/CommandFlags.h
AgeCommit message (Collapse)AuthorFilesLines
2 days[CodeGen][Target] Remove UnsafeFPMath uses (#164549)paperchalice1-2/+0
Remove `UnsafeFPMath` uses, next is removing the command line option.
2025-08-29[IR][CodeGen] Remove "approx-func-fp-math" attribute (#155740)paperchalice1-2/+0
Remove "approx-func-fp-math" attribute and related command line option, users should always use afn flag in IR. Resolve FIXME in `TargetMachine::resetTargetOptions` partially.
2025-07-28Reapply "[llvm] Add CalleeTypeIds field to CallSiteInfo" (#150335) (#150990)Prabhu Rajasekaran1-0/+2
This reverts commit 05e08cdb3e576cc0887d1507ebd2f756460c7db7. Adding the missing -mtriple flags in MIR/X86 test files which caused these tests to fail which was the reason for reverting the patch.
2025-07-23Revert "[llvm] Add CalleeTypeIds field to CallSiteInfo" (#150335)Haowei1-2/+0
Reverts llvm/llvm-project#87574, which breaks LLVM :: CodeGen/MIR/X86/call-site-info-ambiguous-indirect-call-typeid.mir tests on linux-arm64 builders.
2025-07-23[llvm] Add CalleeTypeIds field to CallSiteInfoPrabhu Rajasekaran1-0/+2
Introducing `EnableCallGraphSection` target option to add CalleeTypeIds field in CallSiteInfo. Read the callee type ids in and out by the MIR parser/printer. Reviewers: ilovepi Reviewed By: ilovepi Pull Request: https://github.com/llvm/llvm-project/pull/87574
2025-05-28[llvm] annotate interfaces in llvm/CGData and llvm/CodeGen for DLL export ↵Andrew Rogers1-78/+83
(#140823) ## Purpose This patch is one in a series of code-mods that annotate LLVM’s public interface for export. This patch annotates the `llvm/CGData` and `llvm/CodeGen` libraries. These annotations currently have no meaningful impact on the LLVM build; however, they are a prerequisite to support an LLVM Windows DLL (shared library) build. ## Background This effort is tracked in #109483. Additional context is provided in [this discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307), and documentation for `LLVM_ABI` and related annotations is found in the LLVM repo [here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst). The bulk of these changes were generated automatically using the [Interface Definition Scanner (IDS)](https://github.com/compnerd/ids) tool, followed formatting with `git clang-format`. The following manual adjustments were also applied after running IDS on Linux: - Add `LLVM_ABI` to a subset of private class methods and fields that require export - Add `LLVM_TEMPLATE_ABI` and `LLVM_EXPORT_TEMPLATE` to exported instantiated templates defined via X-macro - Add `LLVM_ABI_FRIEND` to friend member functions declared with `LLVM_ABI` - Explicitly make classes non-copyable where needed to due IDS adding LLVM_ABI at the class level - Add `#include "llvm/Support/Compiler.h"` to files where it was not auto-added by IDS due to no pre-existing block of include statements. - Add `LLVM_ABI` to a small number of symbols that require export but are not declared in headers ## Validation Local builds and tests to validate cross-platform compatibility. This included llvm, clang, and lldb on the following configurations: - Windows with MSVC - Windows with Clang - Linux with GCC - Linux with Clang - Darwin with Clang
2025-01-28[AsmPrinter][ELF] Support profile-guided section prefix for jump tables' ↵Mingming Liu1-0/+2
(read-only) data sections (#122215) https://github.com/llvm/llvm-project/pull/122183 adds a codegen pass to infer machine jump table entry's hotness from the MBB hotness. This is a follow-up PR to produce `.hot` and or `.unlikely` section prefix for jump table's (read-only) data sections in the relocatable `.o` files. When this patch is enabled, linker will see {`.rodata`, `.rodata.hot`, `.rodata.unlikely`} in input sections. It can map `.rodata.hot` and `.rodata` in the input sections to `.rodata.hot` in the executable, and map `.rodata.unlikely` into `.rodata` with a pending extension to `--keep-text-section-prefix` like https://github.com/llvm/llvm-project/commit/059e7cbb66a30ce35f3ee43197eed1a106b50c5b, or with a linker script. 1. To partition hot and jump tables, the AsmPrinter pass slices a function's jump table indices into two groups, one for hot and the other for cold jump tables. It then emits hot jump tables into a `.hot`-prefixed data section and cold ones into a `.unlikely`-prefixed data section, retaining the relative order of `LJT<N>` labels within each group. 2. [ELF only] To have data sections with _dynamic_ names (e.g., `.rodata.hot[.func]`), we implement `TargetLoweringObjectFile::getSectionForJumpTable` method that accepts a `MachineJumpTableEntry` parameter, and update `selectELFSectionForGlobal` to generate `.hot` or `.unlikely` based on MJTE's hotness. - The dynamic JT section name doesn't depend on `-ffunction-section=true` or `-funique-section-names=true`, even though it leverages the similar underlying mechanism to have a MCSection with on-demand name as `-ffunction-section` does. 3. The new code path is off by default. - Typically, `TargetOptions` conveys clang or LLVM tools' options to code generation passes. To follow the pattern, add option `EnableStaticDataPartitioning` bit in `TargetOptions` and make it readable through `TargetMachine`. - To enable the new code path in tools like `llc`, `partition-static-data-sections` option is introduced in `CodeGen/CommandFlags.h/cpp`. - A subsequent patch ([draft](https://github.com/llvm/llvm-project/commit/8f36a1374365862b3ca9be5615dd38f02a318c45)) will add a clang option to enable the new code path. --------- Co-authored-by: Ellis Hoag <ellis.sparky.hoag@gmail.com>
2024-05-07[Clang] -fseparate-named-sections option (#91028)Petr Hosek1-0/+2
When set, the compiler will use separate unique sections for global symbols in named special sections (e.g. symbols that are annotated with __attribute__((section(...)))). Doing so enables linker GC to collect unused symbols without having to use a different section per-symbol.
2024-03-06[MC] Move CompressDebugSections/RelaxELFRelocations from ↵Fangrui Song1-2/+0
TargetOptions/MCAsmInfo to MCTargetOptions The convention is for such MC-specific options to reside in MCTargetOptions. However, CompressDebugSections/RelaxELFRelocations do not follow the convention: `CompressDebugSections` is defined in both TargetOptions and MCAsmInfo and there is forwarding complexity. Move the option to MCTargetOptions and hereby simplify the code. Rename the misleading RelaxELFRelocations to X86RelaxRelocations. llvm-mc -relax-relocations and llc -x86-relax-relocations can now be unified.
2024-02-01[SHT_LLVM_BB_ADDR_MAP] Allow basic-block-sections and labels be used ↵Rahman Lavaee1-0/+2
together by decoupling the handling of the two features. (#74128) Today `-split-machine-functions` and `-fbasic-block-sections={all,list}` cannot be combined with `-basic-block-sections=labels` (the labels option will be ignored). The inconsistency comes from the way basic block address map -- the underlying mechanism for basic block labels -- encodes basic block addresses (https://lists.llvm.org/pipermail/llvm-dev/2020-July/143512.html). Specifically, basic block offsets are computed relative to the function begin symbol. This relies on functions being contiguous which is not the case for MFS and basic block section binaries. This means Propeller cannot use binary profiles collected from these binaries, which limits the applicability of Propeller for iterative optimization. To make the `SHT_LLVM_BB_ADDR_MAP` feature work with basic block section binaries, we propose modifying the encoding of this section as follows. First let us review the current encoding which emits the address of each function and its number of basic blocks, followed by basic block entries for each basic block. | | | |--|--| | Address of the function | Function Address | | Number of basic blocks in this function | NumBlocks | | BB entry 1 | BB entry 2 | ... | BB entry #NumBlocks To make this work for basic block sections, we treat each basic block section similar to a function, except that basic block sections of the same function must be encapsulated in the same structure so we can map all of them to their single function. We modify the encoding to first emit the number of basic block sections (BB ranges) in the function. Then we emit the address map of each basic block section section as before: the base address of the section, its number of blocks, and BB entries for its basic block. The first section in the BB address map is always the function entry section. | | | |--|--| | Number of sections for this function | NumBBRanges | | Section 1 begin address | BaseAddress[1] | | Number of basic blocks in section 1 | NumBlocks[1] | | BB entries for Section 1 |..................| | Section #NumBBRanges begin address | BaseAddress[NumBBRanges] | | Number of basic blocks in section #NumBBRanges | NumBlocks[NumBBRanges] | | BB entries for Section #NumBBRanges The encoding of basic block entries remains as before with the minor change that each basic block offset is now computed relative to the begin symbol of its containing BB section. This patch adds a new boolean codegen option `-basic-block-address-map`. Correspondingly, the front-end flag `-fbasic-block-address-map` and LLD flag `--lto-basic-block-address-map` are introduced. Analogously, we add a new TargetOption field `BBAddrMap`. This means BB address maps are either generated for all functions in the compiling unit, or for none (depending on `TargetOptions::BBAddrMap`). This patch keeps the functionality of the old `-fbasic-block-sections=labels` option but does not remove it. A subsequent patch will remove the obsolete option. We refactor the `BasicBlockSections` pass by separating the BB address map and BB sections handing to their own functions (named `handleBBAddrMap` and `handleBBSections`). `handleBBSections` renumbers basic blocks and places them in their assigned sections. `handleBBAddrMap` is invoked after `handleBBSections` (if requested) and only renumbers the blocks. - New tests added: - Two tests basic-block-address-map-with-basic-block-sections.ll and basic-block-address-map-with-mfs.ll to exercise the combination of `-basic-block-address-map` with `-basic-block-sections=list` and '-split-machine-functions`. - A driver sanity test for the `-fbasic-block-address-map` option (basic-block-address-map.c). - An LLD test for testing the `--lto-basic-block-address-map` option. This reuses the LLVM IR from `lld/test/ELF/lto/basic-block-sections.ll`. - Renamed and modified the two existing codegen tests for basic block address map (`basic-block-sections-labels-functions-sections.ll` and `basic-block-sections-labels.ll`) - Removed `SHT_LLVM_BB_ADDR_MAP_V0` tests. Full deprecation of `SHT_LLVM_BB_ADDR_MAP_V0` and `SHT_LLVM_BB_ADDR_MAP` version less than 2 will happen in a separate PR in a few months.
2024-01-23[RISCV] Support TLSDESC in the RISC-V backend (#66915)Paul Kirth1-0/+3
This patch adds basic TLSDESC support in the RISC-V backend. Specifically, we add new relocation types for TLSDESC, as prescribed in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373, and add a new pseudo instruction to simplify code generation. This patch does not try to optimize the local dynamic case, which can be improved in separate patches. Linker side changes will also be handled separately. The current implementation is only enabled when passing the new `-enable-tlsdesc` codegen flag.
2023-11-01[CodeGen] Remove unused declaration getOverrideStackAlignmentKazu Hirata1-2/+0
The corresponding function definition was removed by: commit 3787ee457173c3612aac4c9b1a2b6d6ab0202616 Author: Nick Desaulniers <ndesaulniers@google.com> Date: Tue Jun 8 08:57:12 2021 -0700
2023-10-04Introduce and use codegen::createTargetMachineForTriple()Alex Richardson1-0/+9
This creates a TargetMachine with the default options (from the command line flags). This allows us to share a bit more code between tools. Differential Revision: https://reviews.llvm.org/D141057
2023-09-14[X86] Introduce a large data threshold for the medium code modelArthur Eubanks1-0/+3
Currently clang's medium code model treats all data as large, putting them in a large data section and using more expensive instruction sequences to access them. Following gcc's -mlarge-data-threshold, which allows putting data under a certain size in a normal data section as opposed to a large data section. This allows using cheaper code sequences to access some portion of data in the binary (which will be implemented in LLVM in a future patch). And under the medium codel mode, only put data above the large data threshold into large data sections, not all data. Reviewed By: MaskRay, rnk Differential Revision: https://reviews.llvm.org/D149288
2023-07-12[libLTO][AIX] Respect `-f[no]-integrated-as` on AIXQiongsi Wu1-0/+2
`libLTO` currently ignores the `-f[no-]integrated-as` flags. This patch teaches `libLTO` to respect them on AIX. The implementation consists of two parts: # Migrate `llc`'s `-no-integrated-as` option to a codegen option so that the option is available to `libLTO`/`lld`/`gold`. # Teach `clang` to pass `-no-integrated-as` accordingly to `libLTO` depending on the `-f[no-]integrated-as` flags. On platforms other than AIX, the `-f[no-]integrated-as` flags are ignored. Reviewed By: MaskRay, steven_wu Differential Revision: https://reviews.llvm.org/D152924
2023-06-11[XRay] Rename XRayOmitFunctionIndex to XRayFunctionIndexFangrui Song1-1/+1
Apply my post-commit comment on D81995. The negative name misguided commit d8a8e5d6240a1db809cd95106910358e69bbf299 (`[clang][cli] Remove marshalling from Opt{In,Out}FFlag`) to: * accidentally flip the option to not emit the xray_fn_idx section. * change -fno-xray-function-index (instead of -fxray-function-index) to emit xray_fn_idx This patch renames XRayOmitFunctionIndex and makes -fxray-function-index emit xray_fn_idx, but the default remains -fno-xray-function-index .
2023-04-23Remove ExplicitEmulatedTLS and simplify -femulated-tls handlingFangrui Song1-0/+1
Currently clangDriver passes -femulated-tls and -fno-emulated-tls to cc1. cc1 forwards the option to LLVMCodeGen and ExplicitEmulatedTLS is used to decide the value. Simplify this by moving the Clang decision to clangDriver and moving the LLVM decision to InitTargetOptionsFromCodeGenFlags.
2023-03-23[AIX][CodeGen] Storage Locations for Constant PointersQiongsi Wu1-0/+2
This patch adds an `llc` option `-mroptr` to specify storage locations for constant pointers on AIX. When the `-mroptr` option is specified, constant pointers, virtual function tables, and virtual type tables are placed in read-only storage. Otherwise, by default, pointers, virtual function tables, and virtual type tables are placed are placed in read/write storage. https://reviews.llvm.org/D144190 enables the `-mroptr` option for `clang`. Reviewed By: hubert.reinterpretcast, stephenpeckham, myhsu, MaskRay, serge-sans-paille Differential Revision: https://reviews.llvm.org/D144189
2023-03-14Remove -lower-global-dtors-via-cxa-atexit flagJulian Lettner1-2/+0
Remove the `-lower-global-dtors-via-cxa-atexit` escape hatch introduced in D121736 [1], which switched the default lowering of global destructors on MachO to use `__cxa_atexit()` to avoid emitting deprecated `__mod_term_func` sections. I added this flag as an escape hatch in case the switch causes any problems. We didn't discover any problems so now we can remove it. [1] https://reviews.llvm.org/D121736 rdar://90277838 Differential Revision: https://reviews.llvm.org/D145715
2022-12-13[CodeGen] llvm::Optional => std::optionalFangrui Song1-1/+1
2022-12-03CodeGen/CommandFlags: Convert Optional to std::optionalFangrui Song1-4/+4
2022-12-03Convert Optional<CodeModel> to std::optional<CodeModel>Krzysztof Parzyszek1-1/+2
2022-03-23Reland "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"Julian Lettner1-0/+2
For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with `__cxa_atexit` calls to avoid emitting the deprecated `__mod_term_func`. Reuse the existing `WebAssemblyLowerGlobalDtors.cpp` to accomplish this. Enable fallback to the old behavior via Clang driver flag (`-fregister-global-dtors-with-atexit`) or llc / code generation flag (`-lower-global-dtors-via-cxa-atexit`). This escape hatch will be removed in the future. Differential Revision: https://reviews.llvm.org/D121736
2022-03-23Revert "Lower `@llvm.global_dtors` using `__cxa_atexit` on MachO"Zequan Wu1-2/+0
This reverts commit 22570bac694396514fff18dec926558951643fa6.
2022-03-17Lower `@llvm.global_dtors` using `__cxa_atexit` on MachOJulian Lettner1-0/+2
For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with `__cxa_atexit` calls to avoid emitting the deprecated `__mod_term_func`. Reuse the existing `WebAssemblyLowerGlobalDtors.cpp` to accomplish this. Enable fallback to the old behavior via Clang driver flag (`-fregister-global-dtors-with-atexit`) or llc / code generation flag (`-lower-global-dtors-via-cxa-atexit`). This escape hatch will be removed in the future. Differential Revision: https://reviews.llvm.org/D121736
2022-03-16Cleanup codegen includesserge-sans-paille1-5/+3
This is a (fixed) recommit of https://reviews.llvm.org/D121169 after: 1061034926 before: 1063332844 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D121681
2022-03-15Revert rG9c542a5a4e1ba36c24e48185712779df52b7f7a6 "Lower ↵Simon Pilgrim1-2/+0
`@llvm.global_dtors` using `__cxa_atexit` on MachO" Mane of the build bots are complaining: Unknown command line argument '-lower-global-dtors'
2022-03-14Lower `@llvm.global_dtors` using `__cxa_atexit` on MachOJulian Lettner1-0/+2
For MachO, lower `@llvm.global_dtors` into `@llvm_global_ctors` with `__cxa_atexit` calls to avoid emitting the deprecated `__mod_term_func`. Reuse the existing `WebAssemblyLowerGlobalDtors.cpp` to accomplish this. Enable fallback to the old behavior via Clang driver flag (`-fregister-global-dtors-with-atexit`) or llc / code generation flag (`-lower-global-dtors-via-cxa-atexit`). This escape hatch will be removed in the future. Differential Revision: https://reviews.llvm.org/D121327
2022-03-10Revert "Cleanup codegen includes"Nico Weber1-3/+5
This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20. Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang, and many LLVM tests, see comments on https://reviews.llvm.org/D121169
2022-03-10Cleanup codegen includesserge-sans-paille1-5/+3
after: 1061034926 before: 1063332844 Differential Revision: https://reviews.llvm.org/D121169
2022-02-10Reland "[clang-cl] Support the /JMC flag"Yuanfang Chen1-0/+2
This relands commit b380a31de084a540cfa38b72e609b25ea0569bb7. Restrict the tests to Windows only since the flag symbol hash depends on system-dependent path normalization.
2022-02-10Revert "[clang-cl] Support the /JMC flag"Yuanfang Chen1-2/+0
This reverts commit bd3a1de683f80d174ea9c97000db3ec3276bc022. Break bots: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8822587673277278177/overview
2022-02-10[clang-cl] Support the /JMC flagYuanfang Chen1-0/+2
The introduction and some examples are on this page: https://devblogs.microsoft.com/cppblog/announcing-jmc-stepping-in-visual-studio/ The `/JMC` flag enables these instrumentations: - Insert at the beginning of every function immediately after the prologue with a call to `void __fastcall __CheckForDebuggerJustMyCode(unsigned char *JMC_flag)`. The argument for `__CheckForDebuggerJustMyCode` is the address of a boolean global variable (the global variable is initialized to 1) with the name convention `__<hash>_<filename>`. All such global variables are placed in the `.msvcjmc` section. - The `<hash>` part of `__<hash>_<filename>` has a one-to-one mapping with a directory path. MSVC uses some unknown hashing function. Here I used DJB. - Add a dummy/empty COMDAT function `__JustMyCode_Default`. - Add `/alternatename:__CheckForDebuggerJustMyCode=__JustMyCode_Default` link option via ".drectve" section. This is to prevent failure in case `__CheckForDebuggerJustMyCode` is not provided during linking. Implementation: All the instrumentations are implemented in an IR codegen pass. The pass is placed immediately before CodeGenPrepare pass. This is to not interfere with mid-end optimizations and make the instrumentation target-independent (I'm still working on an ELF port in a separate patch). Reviewed By: hans Differential Revision: https://reviews.llvm.org/D118428
2022-02-02[PowerPC] Scalar IBM MASS library conversion passMasoud Ataei1-0/+2
This patch introduces the conversions from math function calls to MASS library calls. To resolves calls generated with these conversions, one need to link libxlopt.a library. This patch is tested on PowerPC Linux and AIX. Differential: https://reviews.llvm.org/D101759 Reviewer: bmahjour
2021-11-30[DebugInfo][InstrRef] Pre-land on-by-default-for-x86 changesJeremy Morse1-0/+5
Over in D114631 and [0] there's a plan for turning instruction referencing on by default for x86. This patch adds / removes all the relevant bits of code, with the aim that the final patch is extremely small, for an easy revert. It should just be a condition in CommandFlags.cpp and removing the XFail on instr-ref-flag.ll. [0] https://lists.llvm.org/pipermail/llvm-dev/2021-November/153653.html
2021-09-22[CSSPGO] Set PseudoProbeInserter as a default pass.Hongtao Yu1-2/+0
Currenlty PseudoProbeInserter is a pass conditioned on a target switch. It works well with a single clang invocation. It doesn't work so well when the backend is called separately (i.e, through the linker or llc), where user has always to pass -pseudo-probe-for-profiling explictly. I'm making the pass a default pass that requires no command line arg to trigger, but will be actually run depending on whether the CU comes with `llvm.pseudo_probe_desc` metadata. Reviewed By: wenlei Differential Revision: https://reviews.llvm.org/D110209
2021-09-21[CodeGen] Remove redundant declaration getFileType (NFC)Kazu Hirata1-1/+0
2021-09-16Add a command-line flag to control the Swift extended async frame info.Doug Gregor1-0/+2
Introduce a new command-line flag `-swift-async-fp={auto|always|never}` that controls how code generation sets the Swift extended async frame info bit. There are three possibilities: * `auto`: which determines how to set the bit based on deployment target, either statically or dynamically via `swift_async_extendedFramePointerFlags`. * `always`: the default, always set the bit statically, regardless of deployment target. * `never`: never set the bit, regardless of deployment target. Patch by Doug Gregor <dgregor@apple.com> Reviewed By: doug.gregor Differential Revision: https://reviews.llvm.org/D109392
2021-08-04[CodeGen] Add -align-loopsFangrui Song1-0/+2
to `lib/CodeGen/CommandFlags.cpp`. It can replace -x86-experimental-pref-loop-alignment=. The loop alignment is only used by MachineBlockPlacement. The implementation uses a new `llvm::TargetOptions` for now, as an IR function attribute/module flags metadata may be overkill. This is the llvm part of D106701.
2021-05-21[IR] make stack-protector-guard-* flags into module attrsNick Desaulniers1-7/+0
D88631 added initial support for: - -mstack-protector-guard= - -mstack-protector-guard-reg= - -mstack-protector-guard-offset= flags, and D100919 extended these to AArch64. Unfortunately, these flags aren't retained for LTO. Make them module attributes rather than TargetOptions. Link: https://github.com/ClangBuiltLinux/linux/issues/1378 Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D102742
2021-05-12[Debug-Info] add -gstrict-dwarf support in backendChen Zheng1-0/+2
Reviewed By: dblaikie, probinson Differential Revision: https://reviews.llvm.org/D100826
2021-04-27[CodeGenOptions] make StackProtectorGuardOffset signedNick Desaulniers1-1/+1
GCC supports negative values for -mstack-protector-guard-offset=, this should be a signed value. Pre-req to D100919. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101325
2021-04-22[IR][sanitizer] Add module flag "frame-pointer" and set it for cc1 ↵Fangrui Song1-1/+1
-mframe-pointer={non-leaf,all} The Linux kernel objtool diagnostic `call without frame pointer save/setup` arise in multiple instrumentation passes (asan/tsan/gcov). With the mechanism introduced in D100251, it's trivial to respect the command line -m[no-]omit-leaf-frame-pointer/-f[no-]omit-frame-pointer, so let's do it. Fix: https://github.com/ClangBuiltLinux/linux/issues/1236 (tsan) Fix: https://github.com/ClangBuiltLinux/linux/issues/1238 (asan) Also document the function attribute "frame-pointer" which is long overdue. Differential Revision: https://reviews.llvm.org/D101016
2021-01-30[llvm] Add missing header guards (NFC)Kazu Hirata1-0/+5
Identified with llvm-header-guard.
2020-12-11[AIX][XCOFF] emit traceback table for function in aixdiggerlin1-0/+2
SUMMARY: 1. added a new option -xcoff-traceback-table to control whether generate traceback table for function. 2. implement the functionality of emit traceback table of a function. Reviewers: hubert.reinterpretcast, Jason Liu Differential Revision: https://reviews.llvm.org/D92398
2020-12-02[CSSPGO] Pseudo probes for function calls.Hongtao Yu1-0/+2
An indirect call site needs to be probed for its potential call targets. With CSSPGO a direct call also needs a probe so that a calling context can be represented by a stack of callsite probes. Unlike pseudo probes for basic blocks that are in form of standalone intrinsic call instructions, pseudo probes for callsites have to be attached to the call instruction, thus a separate instruction would not work. One possible way of attaching a probe to a call instruction is to use a special metadata that carries information about the probe. The special metadata will have to make its way through the optimization pipeline down to object emission. This requires additional efforts to maintain the metadata in various places. Given that the `!dbg` metadata is a first-class metadata and has all essential support in place , leveraging the `!dbg` metadata as a channel to encode pseudo probe information is probably the easiest solution. With the requirement of not inflating `!dbg` metadata that is allocated for almost every instruction, we found that the 32-bit DWARF discriminator field which mainly serves AutoFDO can be reused for pseudo probes. DWARF discriminators distinguish identical source locations between instructions and with pseudo probes such support is not required. In this change we are using the discriminator field to encode the ID and type of a callsite probe and the encoded value will be unpacked and consumed right before object emission. When a callsite is inlined, the callsite discriminator field will go with the inlined instructions. The `!dbg` metadata of an inlined instruction is in form of a scope stack. The top of the stack is the instruction's original `!dbg` metadata and the bottom of the stack is for the original callsite of the top-level inliner. Except for the top of the stack, all other elements of the stack actually refer to the nested inlined callsites whose discriminator field (which actually represents a calliste probe) can be used together to represent the inline context of an inlined PseudoProbeInst or CallInst. To avoid collision with the baseline AutoFDO in various places that handles dwarf discriminators where a check against the `-pseudo-probe-for-profiling` switch is not available, a special encoding scheme is used to tell apart a pseudo probe discriminator from a regular discriminator. For the regular discriminator, if all lowest 3 bits are non-zero, it means the discriminator is basically empty and all higher 29 bits can be reversed for pseudo probe use. Callsite pseudo probes are inserted in `SampleProfileProbePass` and a target-independent MIR pass `PseudoProbeInserter` is added to unpack the probe ID/type from `!dbg`. Note that with this work the switch -debug-info-for-profiling will not work with -pseudo-probe-for-profiling anymore. They cannot be used at the same time. Reviewed By: wmi Differential Revision: https://reviews.llvm.org/D91756
2020-11-24[AIX] Add mabi=vec-extabi options to enable the AIX extended and default ↵Zarko Todorovski1-0/+2
vector ABIs. Added support for the options mabi=vec-extabi and mabi=vec-default which are analogous to qvecnvol and qnovecnvol when using XL on AIX. The extended Altivec ABI on AIX is enabled using mabi=vec-extabi in clang and vec-extabi in llc. Reviewed By: Xiangling_L, DiggerLin Differential Revision: https://reviews.llvm.org/D89684
2020-10-22[X86] Support customizing stack protector guardXiang1 Zhang1-0/+7
Reviewed By: nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D88631
2020-10-14[AIX] Turn -fdata-sections on by default in Clangjasonliu1-3/+8
Summary: This patch does the following: 1. Make InitTargetOptionsFromCodeGenFlags() accepts Triple as a parameter, because some options' default value is triple dependant. 2. DataSections is turned on by default on AIX for llc. 3. Test cases change accordingly because of the default behaviour change. 4. Clang Driver passes in -fdata-sections by default on AIX. Reviewed By: MaskRay, DiggerLin Differential Revision: https://reviews.llvm.org/D88737
2020-10-08[AIX] add new option -mignore-xcoff-visibilitydiggerlin1-0/+2
SUMMARY: In IBM compiler xlclang , there is an option -fnovisibility which suppresses visibility. For more details see: https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html. We need to add the option -mignore-xcoff-visibility for compatibility with the IBM AIX OS (as the option is enabled by default in AIX). With this option llvm does not emit any visibility attribute to ASM or XCOFF object file. The option only work on the AIX OS, for other non-AIX OS using the option will report an unsupported options error. In AIX OS: 1.1 the option -mignore-xcoff-visibility is enabled by default , if there is not -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command . 1.2 if there is -fvisibility=* explicitly but not -mignore-xcoff-visibility explicitly in the clang command. it will generate visibility attributes. 1.3 if there are both -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command. The option "-mignore-xcoff-visibility" wins , it do not emit the visibility attribute. The option -mignore-xcoff-visibility has no effect on visibility attribute when compile with -emit-llvm option to generated LLVM IR. Reviewer: daltenty,Jason Liu Differential Revision: https://reviews.llvm.org/D87451
generated by cgit v1.1 at 2025-10-24 10:30:27 +0000