aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode
AgeCommit message (Collapse)AuthorFilesLines
2023-12-11[Bitcode] Check validity of fcmp/icmp predicateNikita Popov1-5/+10
The predicate should match the operand types.
2023-12-11[Bitcode] Check type of alloca size argumentNikita Popov1-0/+3
This must be an integer. This check is present in LLParser but not the BitcodeReader.
2023-12-11[Bitcode] Add missing getValue() return value checksNikita Popov1-0/+4
2023-12-08[Bitcode] Remove an unnecessary include (NFC)Kazu Hirata1-1/+0
2023-12-06[ThinLTO] Add tail call flag to call edges in summary (#74043)Teresa Johnson2-63/+72
This adds support for a HasTailCall flag on function call edges in the ThinLTO summary. It is intended for use in aiding discovery of missing frames from tail calls in profiled call stacks for MemProf of profiled binaries that did not disable tail call elimination. A follow on change will add the use of this new flag during MemProf context disambiguation. The new flag is encoded in the bitcode along with either the hotness flag from the profile, or the relative block frequency under the -write-relbf-to-summary flag when there is no profile data. Because we now will always have some additional call edge information, I have removed the non-profile function summary record format, and we simply encode the tail call flag along with a hotness type of none when there is no profile information or relative block frequency. The change of record format and name caused most of the test case changes. I have added explicit testing of generation of the new tail call flag into the bitcode and IR assembly format as part of the changes to llvm/test/Bitcode/thinlto-function-summary-refgraph.ll. I have also added round trip testing through assembly and bitcode to llvm/test/Assembler/thinlto-summary.ll.
2023-12-06[Bitcode] Check for missing load typeNikita Popov1-4/+6
We perform do this check independently of whether this is an old or new style load. Fixes https://github.com/llvm/llvm-project/issues/74556.
2023-12-05[llvm][IR] Add per-global code model attribute (#72077)hev2-2/+28
This adds a per-global code model attribute, which can override the target's code model to access global variables. Suggested-by: Arthur Eubanks <aeubanks@google.com> Link: https://discourse.llvm.org/t/how-to-best-implement-code-model-overriding-for-certain-values/71816 Link: https://discourse.llvm.org/t/rfc-add-per-global-code-model-attribute/74944
2023-11-24[IR] Add disjoint flag for Or instructions. (#72583)Craig Topper2-1/+6
This flag indicates that every bit is known to be zero in at least one of the inputs. This allows the Or to be treated as an Add since there is no possibility of a carry from any bit. If the flag is present and this property does not hold, the result is poison. This makes it easier to reverse the InstCombine transform that turns Add into Or. This is inspired by a comment here https://github.com/llvm/llvm-project/pull/71955#discussion_r1391614578 Discourse thread https://discourse.llvm.org/t/rfc-add-or-disjoint-flag/75036
2023-11-17Reapply "[DebugInfo] Make DIArgList inherit from Metadata and always unique"Stephen Tozer1-5/+7
This reverts commit 0fd5dc94380d5fe666dc6c603b4bb782cef743e7. The original commit removed DIArgLists from being in an MDNode map, but did not insert a new `delete` in the LLVMContextImpl destructor. This reapply adds that call to delete, preventing a memory leak.
2023-11-17Revert "[DebugInfo] Make DIArgList inherit from Metadata and always unique" ↵Stephen Tozer1-7/+5
(#72682) Reverts llvm/llvm-project#72147 Reverted due to buildbot failure: https://lab.llvm.org/buildbot/#/builders/5/builds/38410
2023-11-17[DebugInfo] Make DIArgList inherit from Metadata and always unique (#72147)Stephen Tozer1-5/+7
This patch changes the `DIArgList` class's inheritance from `MDNode` to `Metadata, ReplaceableMetadataImpl`, and ensures that it is always unique, i.e. a distinct DIArgList should never be produced. This should not result in any changes to IR or bitcode parsing and printing, as the format for DIArgList is unchanged, and the order in which it appears should also be identical. As a minor note, this patch also fixes a gap in the verifier, where the ValueAsMetadata operands to a DIArgList would not be visited.
2023-11-16[llvm] Remove no-op ptr-to-ptr bitcasts (NFC)Youngsuk Kim1-5/+1
Opaque ptr cleanup effort (NFC).
2023-11-09[DebugInfo][RemoveDIs] Add conversion utilities for new-debug-info formatJeremy Morse1-0/+19
This patch plumbs the command line --experimental-debuginfo-iterators flag in to the pass managers, so that modules can be converted to the new format, passes run, then converted back to the old format. That allows developers to test-out the new debuginfo representation across some part of LLVM with no further work, and from the command line. It also installs flag-catchers at the various points that bitcode and textual IR can egress from a process, and temporarily convert the module to dbg.value format when doing so. No tests alas as it's designed to be transparent. Differential Revision: https://reviews.llvm.org/D154372
2023-11-09[Coroutines] Introduce [[clang::coro_only_destroy_when_complete]] (#71014)Chuanqi Xu2-0/+4
Close https://github.com/llvm/llvm-project/issues/56980. This patch tries to introduce a light-weight optimization attribute for coroutines which are guaranteed to only be destroyed after it reached the final suspend. The rationale behind the patch is simple. See the example: ```C++ A foo() { dtor d; co_await something(); dtor d1; co_await something(); dtor d2; co_return 43; } ``` Generally the generated .destroy function may be: ```C++ void foo.destroy(foo.Frame *frame) { switch(frame->suspend_index()) { case 1: frame->d.~dtor(); break; case 2: frame->d.~dtor(); frame->d1.~dtor(); break; case 3: frame->d.~dtor(); frame->d1.~dtor(); frame->d2.~dtor(); break; default: // coroutine completed or haven't started break; } frame->promise.~promise_type(); delete frame; } ``` Since the compiler need to be ready for all the cases that the coroutine may be destroyed in a valid state. However, from the user's perspective, we can understand that certain coroutine types may only be destroyed after it reached to the final suspend point. And we need a method to teach the compiler about this. Then this is the patch. After the compiler recognized that the coroutines can only be destroyed after complete, it can optimize the above example to: ```C++ void foo.destroy(foo.Frame *frame) { frame->promise.~promise_type(); delete frame; } ``` I spent a lot of time experimenting and experiencing this in the downstream. The numbers are really good. In a real-world coroutine-heavy workload, the size of the build dir (including .o files) reduces 14%. And the size of final libraries (excluding the .o files) reduces 8% in Debug mode and 1% in Release mode.
2023-11-08Revert "[DebugMetadata][DwarfDebug] Support function-local types in lexical ↵Vladislav Dzhidzhoev1-78/+33
block scopes (4/7)" This caused assert: llvm/llvm/lib/CodeGen/AsmPrinter/DwarfFile.cpp:110: void llvm::DwarfFile::addScopeVariable(LexicalScope *, DbgVariable *): Assertion `Ret.second' failed. See comments https://reviews.llvm.org/D144006#4656350. This reverts commit 3b449bd46a11a55a40cbc0016a99b202fa05248e.
2023-11-07[NFC] Remove Type::getInt8PtrTy (#71029)Paulo Matos1-1/+1
Replace this with PointerType::getUnqual(). Followup to the opaque pointer transition. Fixes an in-code TODO item.
2023-11-03[IR] Remove zext and sext constant expressions (#71040)Nikita Popov1-0/+3
Remove support for zext and sext constant expressions. All places creating them have been removed beforehand, so this just removes the APIs and uses of these constant expressions in tests. There is some additional cleanup that can be done on top of this, e.g. we can remove the ZExtInst vs ZExtOperator footgun. This is part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
2023-11-02[DebugMetadata][DwarfDebug] Support function-local types in lexical block ↵Vladislav Dzhidzhoev1-33/+78
scopes (4/7) RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544 Similar to imported declarations, the patch tracks function-local types in DISubprogram's 'retainedNodes' field. DwarfDebug is adjusted in accordance with the aforementioned metadata change and provided a support of function-local types scoped within a lexical block. The patch assumes that DICompileUnit's 'enums field' no longer tracks local types and DwarfDebug would assert if any locally-scoped types get placed there. Reviewed By: jmmartinez Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com> Differential Revision: https://reviews.llvm.org/D144006
2023-11-01[IR] Add writable attributeNikita Popov2-0/+4
This adds a writable attribute, which in conjunction with dereferenceable(N) states that a spurious store of N bytes is introduced on function entry. This implies that this many bytes are writable without trapping or introducing data races. See https://llvm.org/docs/Atomics.html#optimization-outside-atomic for why the second point is important. This attribute can be added to sret arguments. I believe Rust will also be able to use it for by-value (moved) arguments. Rust likely won't be able to use it for &mut arguments (tree borrows does not appear to allow spurious stores). In this patch the new attribute is only used by LICM scalar promotion. However, the actual motivation for this is to fix a correctness issue in call slot optimization, which needs this attribute to avoid optimization regressions. Followup to the discussion on D157499. Differential Revision: https://reviews.llvm.org/D158081
2023-10-30[IR] Add zext nneg flag (#67982)Nikita Popov2-3/+29
Add an nneg flag to the zext instruction, which specifies that the argument is non-negative. Otherwise, the result is a poison value. The primary use-case for the flag is to preserve information when sext gets replaced with zext due to range-based canonicalization. The nneg flag allows us to convert the zext back into an sext later. This is useful for some optimizations (e.g. a signed icmp can fold with sext but not zext), as well as some targets (e.g. RISCV prefers sext over zext). Discourse thread: https://discourse.llvm.org/t/rfc-add-zext-nneg-flag/73914 This patch is based on https://reviews.llvm.org/D156444 by @Panagiotis156, with some implementation simplifications and additional tests. --------- Co-authored-by: Panagiotis K <karouzakispan@gmail.com>
2023-10-22[llvm] Stop including llvm/ADT/iterator_range.h (NFC)Kazu Hirata1-1/+0
Identified with misc-include-cleaner.
2023-10-18[llvm] Use StringRef::contains (NFC)Kazu Hirata1-1/+1
2023-10-18[LLVM] Add new attribute `optdebug` to optimize for debugging (#66632)Stephen Tozer2-0/+4
This patch adds a new fn attribute, `optdebug`, that specifies that optimizations should make decisions that prioritize debug info quality, potentially at the cost of runtime performance. This patch does not add any functional changes triggered by this attribute, only the attribute itself. A subsequent patch will use this flag to disable the post-RA scheduler.
2023-10-16[DebugInfo] Only call upgradeCULocals() at module level (#68965)Nikita Popov1-4/+5
Loading a 2GB bitcode file, I noticed that we spend minutes just running upgradeCULocals(). Apparently it gets invoked every time a metadata block is loaded, which will be once at the module level and then once per function. However, the relevant metadata only exists at the module level, so running this upgrade per function is unnecessary.
2023-10-05[BitcodeReader] Replace unsupported constexprs in metadata with undefNikita Popov3-22/+33
Metadata (via ValueAsMetadata) can reference constant expressions that may no longer be supported. These references can both be in function-local metadata and module metadata, if the same expression is used in multiple functions. At least in theory, such references could also be in metadata proper, rather than just inside ValueAsMetadata references in calls. Instead of trying to expand these expressions (which we can't reliably do), pretend that the constant has been deleted, which means that ValueAsMetadata references will get replaced with undef metadata. Fixes https://github.com/llvm/llvm-project/issues/68281.
2023-09-30[llvm] Remove uses of Type::getPointerTo() (NFC)Youngsuk Kim1-1/+1
* Remove if its sole use is to support an unnecessary ptr-to-ptr bitcast (remove the bitcast as well) * Replace with use of other APIs. NFC opaque pointer cleanup effort.
2023-09-29Revert "[DebugMetadata][DwarfDebug] Support function-local types in lexical ↵Hans Wennborg1-53/+33
block scopes (4/7)" This caused asserts: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2331: virtual void llvm::DwarfDebug::endFunctionImpl(const llvm::MachineFunction *): Assertion `LScopes.getAbstractScopesList().size() == NumAbstractSubprograms && "getOrCreateAbstractScope() inserted an abstract subprogram scope"' failed. See comment on the code review for reproducer. > RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544 > > Similar to imported declarations, the patch tracks function-local types in > DISubprogram's 'retainedNodes' field. DwarfDebug is adjusted in accordance with > the aforementioned metadata change and provided a support of function-local > types scoped within a lexical block. > > The patch assumes that DICompileUnit's 'enums field' no longer tracks local > types and DwarfDebug would assert if any locally-scoped types get placed there. > > Reviewed By: jmmartinez > > Differential Revision: https://reviews.llvm.org/D144006 This reverts commit f8aab289b5549086062588fba627b0e4d3a5ab15.
2023-09-28[Bitcode] Support expanding constant expressions in function metadataNikita Popov3-13/+21
This fixes the bitcode upgrade failure reported in https://reviews.llvm.org/D155924#4616789. The expansion always happens in the entry block, so this may be inaccurate if there are trapping constant expressions.
2023-09-26[DebugMetadata][DwarfDebug] Support function-local types in lexical block ↵Vladislav Dzhidzhoev1-33/+53
scopes (4/7) RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544 Similar to imported declarations, the patch tracks function-local types in DISubprogram's 'retainedNodes' field. DwarfDebug is adjusted in accordance with the aforementioned metadata change and provided a support of function-local types scoped within a lexical block. The patch assumes that DICompileUnit's 'enums field' no longer tracks local types and DwarfDebug would assert if any locally-scoped types get placed there. Reviewed By: jmmartinez Differential Revision: https://reviews.llvm.org/D144006
2023-09-26[Bitcode] Add some missing GetTypeByID failure checksNikita Popov1-2/+2
Print an error instead of crashing. Fixes https://github.com/llvm/llvm-project/issues/67388.
2023-09-01[LTO] Remove module id from summary indexTeresa Johnson2-48/+57
The module paths string table mapped to both an id sequentially assigned during LTO linking, and the module hash. The former is leftover from before the module hash was added for caching and subsequently replaced use of the module id when renaming promoted symbols (to avoid affects due to link order changes). The sequentially assigned module id was not removed, however, as it was still a convenience when serializing to/from bitcode and assembly. This patch removes the module id from this table, since it isn't strictly needed and can lead to confusion on when it is appropriate to use (e.g. see fix in D156525). It also takes a (likely not significant) amount of overhead. Where an integer module id is needed (e.g. bitcode writing), one is assigned on the fly. There are a couple of test changes since the paths are now sorted alphanumerically when assigning ids on the fly during assembly writing, in order to ensure deterministic behavior. Differential Revision: https://reviews.llvm.org/D156730
2023-08-23[BitcodeReader] Remove two unused variablesBjorn Pettersson1-2/+2
2023-08-21[IR] Remove SDivOperator/UDivOperator (NFC)Nikita Popov1-1/+1
These haven't been supported as constant expressions for a while already, so having Operator variants of them doesn't make much sense.
2023-07-28[BitcodeReader] Add missing () to disambiguate precedence. NFCJon Roelofs1-1/+1
2023-07-18[Bitcode] Remove uses of isOpaqueOrPointeeTypeEquals() (NFC)Nikita Popov1-27/+5
2023-07-14[llvm] Remove uses of getNonOpaquePointerElementType() (NFC)Nikita Popov1-12/+5
2023-07-14[llvm][clang] Remove uses of isOpaquePointerTy() (NFC)Nikita Popov1-11/+0
This now always returns true (for pointer types).
2023-07-14[llvm] Remove calls to supportsTypedPointers() (NFC)Nikita Popov1-3/+0
Always returns false now.
2023-07-05[llvm] A Unified LTO Bitcode FrontendMatthew Voss2-22/+38
Here's a high level summary of the changes in this patch. For more information on rational, see the RFC. (https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774). - Add config parameter to LTO backend, specifying which LTO mode is desired when using unified LTO. - Add unified LTO flag to the summary index for efficiency. Unified LTO modules can be detected without parsing the module. - Make sure that the ModuleID is generated by incorporating more types of symbols. Differential Revision: https://reviews.llvm.org/D123803
2023-06-27[llvm] Move AttributeMask to a separate headerElliot Goodrich1-0/+1
Move `AttributeMask` out of `llvm/IR/Attributes.h` to a new file `llvm/IR/AttributeMask.h`. After doing this we can remove the `#include <bitset>` and `#include <set>` directives from `Attributes.h`. Since there are many headers including `Attributes.h`, but not needing the definition of `AttributeMask`, this causes unnecessary bloating of the translation units and slows down compilation. This commit adds in the include directive for `llvm/IR/AttributeMask.h` to the handful of source files that need to see the definition. This reduces the total number of preprocessing tokens across the LLVM source files in lib from (roughly) 1,917,509,187 to 1,902,982,273 - a reduction of ~0.76%. This should result in a small improvement in compilation time. Differential Revision: https://reviews.llvm.org/D153728
2023-06-20Revert "Reland "[DebugMetadata][DwarfDebug] Support function-local types in ↵Vladislav Dzhidzhoev1-56/+31
lexical block scopes (4/7)" (2)" This reverts commit cb9ac7051589ea0d05507f9370d0716bef86b4ae. It causes an assert in clang: virtual void llvm::DwarfDebug::endFunctionImpl(const llvm::MachineFunction*): Assertion `LScopes.getAbstractScopesList().size() == NumAbstractSubprograms && "getOrCreateAbstractScope() inserted an abstract subprogram scope"' failed. https://bugs.chromium.org/p/chromium/issues/detail?id=1456288#c2
2023-06-20Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical ↵Vladislav Dzhidzhoev1-31/+56
block scopes (4/7)" (2) Test "local-type-as-template-parameter.ll" is now enabled only for x86_64. Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com> Differential Revision: https://reviews.llvm.org/D144006 Depends on D144005
2023-06-20Revert "Reland "[DebugMetadata][DwarfDebug] Support function-local types in ↵Vladislav Dzhidzhoev1-56/+31
lexical block scopes (4/7)"" This reverts commit 2da45172c4bcd42f704c57c656926f56f32fc5ce. Test local-type-as-template-parameter.ll fails on ppc64-aix.
2023-06-19Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical ↵Vladislav Dzhidzhoev1-31/+56
block scopes (4/7)" Test "local-type-as-template-parameter.ll" now requires linux-system. Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com> Differential Revision: https://reviews.llvm.org/D144006 Depends on D144005
2023-06-19Revert "[DebugMetadata][DwarfDebug] Support function-local types in lexical ↵Vladislav Dzhidzhoev1-56/+31
block scopes (4/7)" This reverts commit 66511b401042f28c74d2ded3aac76d19a53bd7c4. llvm/test/DebugInfo/Generic/local-type-as-template-parameter.ll is broken.
2023-06-19[DebugMetadata][DwarfDebug] Support function-local types in lexical block ↵Vladislav Dzhidzhoev1-31/+56
scopes (4/7) RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544 Similar to imported declarations, the patch tracks function-local types in DISubprogram's 'retainedNodes' field. DwarfDebug is adjusted in accordance with the aforementioned metadata change and provided a support of function-local types scoped within a lexical block. The patch assumes that DICompileUnit's 'enums field' no longer tracks local types and DwarfDebug would assert if any locally-scoped types get placed there. Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com> Differential Revision: https://reviews.llvm.org/D144006 Depends on D144005
2023-06-16Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local ↵Vladislav Dzhidzhoev1-0/+84
imported entities (3/7)" Got rid of non-determinism in MetadataLoader.cpp. Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com> Differential Revision: https://reviews.llvm.org/D144004
2023-06-15Revert "Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of ↵Vladislav Dzhidzhoev1-84/+0
function-local imported entities (3/7)"" This reverts commit fcc3981626821addc6c77b98006d02030b8ceb7f, since Bitcode-upgrading code doesn't seem to be deterministic.
2023-06-15Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local ↵Vladislav Dzhidzhoev1-0/+84
imported entities (3/7)" Run split-dwarf-local-impor3.ll only on x86_64-linux.
2023-06-15Revert "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local ↵Vladislav Dzhidzhoev1-84/+0
imported entities (3/7)" This reverts commit d80fdc6fc1a6e717af1bcd7a7313e65de433ba85. split-dwarf-local-impor3.ll fails because of an issue with Dwo sections emission on Windows platform.
generated by cgit v1.1 at 2025-10-03 17:42:51 +0000