summaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
AgeCommit message (Collapse)Author
2021-05-20[IR][AutoUpgrade] Drop alignment from non-pointer parameters and returnsSteven Wu
This is a follow-up of D102201. After some discussion, it is a better idea to upgrade all invalid uses of alignment attributes on function return values and parameters, not just limited to void function return types. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D102726
2021-05-19[OpaquePtr] Make atomicrmw work with opaque pointersArthur Eubanks
FullTy is only necessary when we need to figure out what type an instruction works with given a pointer's pointee type. However, we just end up using the value operand's type, so FullTy isn't necessary. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D102788
2021-05-19[OpaquePtr] Make GEPs work with opaque pointersArthur Eubanks
No verifier changes needed, the verifier currently doesn't check that the pointer operand's pointee type matches the GEP type. There is a similar check in GetElementPtrInst::Create() though. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D102744
2021-05-18[OpaquePtr] Make loads and stores work with opaque pointersArthur Eubanks
Don't check that types match when the pointer operand is an opaque pointer. I would separate the Assembler and Verifier changes, but verify-uselistorder in the Assembler test ends up running the verifier. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D102450
2021-05-14IR+AArch64: add a "swiftasync" argument attribute.Tim Northover
This extends any frame record created in the function to include that parameter, passed in X22. The new record looks like [X22, FP, LR] in memory, and FP is stored with 0b0001 in bits 63:60 (CodeGen assumes they are 0b0000 in normal operation). The effect of this is that tools walking the stack should expect to see one of three values there: * 0b0000 => a normal, non-extended record with just [FP, LR] * 0b0001 => the extended record [X22, FP, LR] * 0b1111 => kernel space, and a non-extended record. All other values are currently reserved. If compiling for arm64e this context pointer is address-discriminated with the discriminator 0xc31a and the DB (process-specific) key. There is also an "i8** @llvm.swift.async.context.addr()" intrinsic providing front-ends access to this slot (and forcing its creation initialized to nullptr if necessary).
2021-05-13[IR] Introduce the opaque pointer typeArthur Eubanks
The opaque pointer type is essentially just a normal pointer type with a null pointee type. This also adds support for the opaque pointer type to the bitcode reader/writer, as well as to textual IR. To avoid confusion with existing pointer types, we disallow creating a pointer to an opaque pointer. Opaque pointer types should not be widely used at this point since many parts of LLVM still do not support them. The next steps are to add some very simple use cases of opaque pointers to make sure they work, then start pretending that all pointers are opaque pointers and see what breaks. https://lists.llvm.org/pipermail/llvm-dev/2021-May/150359.html Reviewed By: dblaikie, dexonsmith, pcc Differential Revision: https://reviews.llvm.org/D101704
2021-05-13Support unwinding from inline assemblycynecx
I've taken the following steps to add unwinding support from inline assembly: 1) Add a new `unwind` "attribute" (like `sideeffect`) to the asm syntax: ``` invoke void asm sideeffect unwind "call thrower", "~{dirflag},~{fpsr},~{flags}"() to label %exit unwind label %uexit ``` 2.) Add Bitcode writing/reading support + LLVM-IR parsing. 3.) Emit EHLabels around inline assembly lowering (SelectionDAGBuilder + GlobalISel) when `InlineAsm::canThrow` is enabled. 4.) Tweak InstCombineCalls/InlineFunction pass to not mark inline assembly "calls" as nounwind. 5.) Add clang support by introducing a new clobber: "unwind", which lower to the `canThrow` being enabled. 6.) Don't allow unwinding callbr. Reviewed By: Amanieu Differential Revision: https://reviews.llvm.org/D95745
2021-05-11[IR][AutoUpgrade] Drop align attribute from void return typesSteven Wu
Since D87304, `align` become an invalid attribute on none pointer types and verifier will reject bitcode that has invalid `align` attribute. The problem is before the change, DeadArgumentElimination can easily turn a pointer return type into a void return type without removing `align` attribute. Teach Autograde to remove invalid `align` attribute from return types to maintain bitcode compatibility. rdar://77022993 Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D102201
2021-03-29Reapply "OpaquePtr: Turn inalloca into a type attribute"Matt Arsenault
This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29Revert "Reapply "OpaquePtr: Turn inalloca into a type attribute""Oliver Stannard
Reverting because test 'Bindings/Go/go.test' is failing on most buildbots. This reverts commit fc9df309917e57de704f3ce4372138a8d4a23d7a.
2021-03-28Reapply "OpaquePtr: Turn inalloca into a type attribute"Matt Arsenault
This reverts commit 20d5c42e0ef5d252b434bcb610b04f1cb79fe771.
2021-03-28Revert "OpaquePtr: Turn inalloca into a type attribute"Nico Weber
This reverts commit 4fefed65637ec46c8c2edad6b07b5569ac61e9e5. Broke check-clang everywhere.
2021-03-28OpaquePtr: Turn inalloca into a type attributeMatt Arsenault
I think byval/sret and the others are close to being able to rip out the code to support the missing type case. A lot of this code is shared with inalloca, so catch this up to the others so that can happen.
2021-03-22[IR] Add vscale_range IR function attributeBradley Smith
This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-02-22[llvm][Bitcode] Add bitcode reader/writer for DSOLocalEquivalentLeonard Chan
This is necessary for compilation with [thin]lto. Differential Revision: https://reviews.llvm.org/D96170
2021-02-12[LTO] Perform DSOLocal propagation in combined indexWei Wang
Perform DSOLocal propagation within summary list of every GV. This avoids the repeated query of this information during function importing. Differential Revision: https://reviews.llvm.org/D96398
2021-02-11Fix bitcode decoder error in "Encode alignment attribute for `atomicrmw`"James Y Knight
The wrong record field number was being used in bitcode decoding, which broke a self-hosted LTO build. (Yet, somehow, this _doesn't_ seem to have broken simple bitcode encode/decode roundtrip tests, and I'm not sure why...) Fixes commit d06ab79816785fa362e7d96d7a398bea8064cba7
2021-02-11Encode alignment attribute for `cmpxchg`Guillaume Chatelet
This is a follow up patch to D83136 adding the align attribute to `cmpxchg`. See also D83465 for `atomicrmw`. Differential Revision: https://reviews.llvm.org/D87443
2021-02-11Encode alignment attribute for `atomicrmw`Guillaume Chatelet
This is a follow up patch to D83136 adding the align attribute to `atomicwmw`. Differential Revision: https://reviews.llvm.org/D83465
2021-01-27[ThinLTO] Add Visibility bits to GlobalValueSummary::GVFlagsFangrui Song
Imported functions and variable get the visibility from the module supplying the definition. However, non-imported definitions do not get the visibility from (ELF) the most constraining visibility among all modules (Mach-O) the visibility of the prevailing definition. This patch * adds visibility bits to GlobalValueSummary::GVFlags * computes the result visibility and propagates it to all definitions Protected/hidden can imply dso_local which can enable some optimizations (this is stronger than GVFlags::DSOLocal because the implied dso_local can be leveraged for ELF -shared while default visibility dso_local has to be cleared for ELF -shared). Note: we don't have summaries for declarations, so for ELF if a declaration has the most constraining visibility, the result visibility may not be that one. Differential Revision: https://reviews.llvm.org/D92900
2021-01-24[llvm] Use pop_back_val (NFC)Kazu Hirata
2021-01-06[llvm] Use llvm::append_range (NFC)Kazu Hirata
2020-12-30[X86] Add x86_amx type for intel AMX.Luo, Yuanke
The x86_amx is used for AMX intrisics. <256 x i32> is bitcast to x86_amx when it is used by AMX intrinsics, and x86_amx is bitcast to <256 x i32> when it is used by load/store instruction. So amx intrinsics only operate on type x86_amx. It can help to separate amx intrinsics from llvm IR instructions (+-*/). Thank Craig for the idea. This patch depend on https://reviews.llvm.org/D87981. Differential Revision: https://reviews.llvm.org/D91927
2020-12-17[IR][PGO] Add hot func attribute and use hot/cold attribute in func sectionRong Xu
Clang FE currently has hot/cold function attribute. But we only have cold function attribute in LLVM IR. This patch adds support of hot function attribute to LLVM IR. This attribute will be used in setting function section prefix/suffix. Currently .hot and .unlikely suffix only are added in PGO (Sample PGO) compilation (through isFunctionHotInCallGraph and isFunctionColdInCallGraph). This patch changes the behavior. The new behavior is: (1) If the user annotates a function as hot or isFunctionHotInCallGraph is true, this function will be marked as hot. Otherwise, (2) If the user annotates a function as cold or isFunctionColdInCallGraph is true, this function will be marked as cold. The changes are: (1) user annotated function attribute will used in setting function section prefix/suffix. (2) hot attribute overwrites profile count based hotness. (3) profile count based hotness overwrite user annotated cold attribute. The intention for these changes is to provide the user a way to mark certain function as hot in cases where training input is hard to cover all the hot functions. Differential Revision: https://reviews.llvm.org/D92493
2020-12-14[clang][IR] Add support for leaf attributeGulfem Savrun Yeniceri
This patch adds support for leaf attribute as an optimization hint in Clang/LLVM. Differential Revision: https://reviews.llvm.org/D90275
2020-12-11Migrate deprecated DebugLoc::get to DILocation::getFangrui Song
This migrates all LLVM (except Kaleidoscope and CodeGen/StackProtector.cpp) DebugLoc::get to DILocation::get. The CodeGen/StackProtector.cpp usage may have a nullptr Scope and can trigger an assertion failure, so I don't migrate it. Reviewed By: #debug-info, dblaikie Differential Revision: https://reviews.llvm.org/D93087
2020-11-25Adding PoisonValue for representing poison value explicitly in IRZhengyang Liu
Define ConstantData::PoisonValue. Add support for poison value to LLLexer/LLParser/BitcodeReader/BitcodeWriter. Add support for poison value to llvm-c interface. Add support for poison value to OCaml binding. Add m_Poison in PatternMatch. Differential Revision: https://reviews.llvm.org/D71126
2020-11-17Revert "[BitCode] decode nossp fn attr"Nick Desaulniers
This reverts commit 0b11d018cc2f2c6bea5dac8dc72140cdb502ca02. Going with a simpler approach.
2020-10-30BitcodeReader::popValue - pass SmallVectorImpl<> as const reference. NFCI.Simon Pilgrim
Fixes cppcheck warning.
2020-10-26[BitCode] decode nossp fn attrNick Desaulniers
I missed this in https://reviews.llvm.org/D87956. Reviewed By: void Differential Revision: https://reviews.llvm.org/D90177
2020-10-20[IR] Adds mustprogress as a LLVM IR attributeAtmn Patel
This adds the LLVM IR attribute `mustprogress` as defined in LangRef through D86233. This attribute will be applied to functions with in languages like C++ where forward progress is guaranteed. Functions without this attribute are not required to make progress. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D85393
2020-10-16Reapply "OpaquePtr: Add type to sret attribute"Matt Arsenault
This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-10-07Reapply [ADT] function_ref's constructor is unavailable if the argument is ↵Sam McCall
not callable. This reverts commit 281703e67ffaee8e26efef86e0df3e145477f4cb. GCC 5.4 bugs are worked around by avoiding use of variable templates. Differential Revision: https://reviews.llvm.org/D88977
2020-10-07Revert "[ADT] function_ref's constructor is unavailable if the argument is ↵Sam McCall
not callable." This reverts commit 4cae6228d129d4c4dfb156c043977bb6b5690031. Breaks GCC build: http://lab.llvm.org:8011/#/builders/8/builds/33/steps/6/logs/stdio
2020-10-07[ADT] function_ref's constructor is unavailable if the argument is not callable.Sam McCall
This allows overload sets containing function_ref arguments to work correctly Otherwise they're ambiguous as anything "could be" converted to a function_ref. This matches proposed std::function_ref, absl::function_ref, etc. Differential Revision: https://reviews.llvm.org/D88901
2020-09-29Revert "OpaquePtr: Add type to sret attribute"Tres Popp
This reverts commit 55c4ff91bd820d72014f63dcf7f3d5a0d3397986. Issues were introduced as discussed in https://reviews.llvm.org/D88241 where this change made previous bugs in the linker and BitCodeWriter visible.
2020-09-25OpaquePtr: Add type to sret attributeMatt Arsenault
Make the corresponding change that was made for byval in b7141207a483d39b99c2b4da4eb3bb591eca9e1a. Like byval, this requires a bulk update of the test IR tests to include the type before this can be mandatory.
2020-09-09[NFC] Separate bitcode reading for FUNC_CODE_INST_CMPXCHG(_OLD)Guillaume Chatelet
This is preparatory work to unable storing alignment for AtomicCmpXchgInst. See D83136 for context and bug: https://bugs.llvm.org/show_bug.cgi?id=27168 This is the fixed version of D83375, which was submitted and reverted. Differential Revision: https://reviews.llvm.org/D87373
2020-08-14[StackSafety] Use ValueInfo in ParamAccess::CallVitaly Buka
This avoid GUID lookup in Index.findSummaryInModule. Follow up for D81242. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D85269
2020-07-27[NFC] Move BitcodeCommon.h from Bitstream to BitcodeGuillaume Chatelet
2020-07-27[NFC] Replace ".size() < 1" with ".empty()"Guillaume Chatelet
2020-07-27[Alignment][NFC] Update Bitcodewriter to use AlignGuillaume Chatelet
Differential Revision: https://reviews.llvm.org/D83533
2020-07-23[Bitcode] Avoid duplicating linker option when upgradingSteven Wu
Summary: The upgrading path from old ModuleFlag based linker options to the new NamedMetadata based linker option in in materializeMetadata() which gets called once for the module and once for every GV. The linker options are getting dup'ed every time and it can create massive amount of the linker options in the object file that gets created from old bitcode. Fix the problem by checking if the new option exists or not before upgrade again. rdar://64543389 Reviewers: pcc, t.p.northover, dexonsmith, arphaman Reviewed By: arphaman Subscribers: hiraditya, jkorous, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D83688
2020-07-23[Bitcode] Drop invalid branch_weight in BitcodeReaderSteven Wu
Summary: If bitcode reader gets an invalid branch weight, drop that from the inputs. This allows us to read the broken modules we generated before the verifier was able to catch this. rdar://64870641 Reviewers: yrouban, t.p.northover, dexonsmith, arphaman, aprantl Reviewed By: aprantl Subscribers: aprantl, hiraditya, jkorous, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D83699
2020-07-20IR: Define byref parameter attributeMatt Arsenault
This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-07-10Temporarily revert "[NFC] Separate bitcode reading for ↵Eric Christopher
FUNC_CODE_INST_CMPXCHG(_OLD)" as it wasn't NFC and is causing issues with thinlto bitcode reading. I've followed up offline with reproduction instructions and testcases. This reverts commit 30582457b47004dec8a78144abc919a13ccbd08c.
2020-07-10[NFC] Separate bitcode reading for FUNC_CODE_INST_CMPXCHG(_OLD)Guillaume Chatelet
This is preparatory work to unable storing alignment for AtomicCmpXchgInst. See D83136 for context and bug: https://bugs.llvm.org/show_bug.cgi?id=27168 Differential Revision: https://reviews.llvm.org/D83375
2020-07-08[LLVM] Accept `noundef` attribute in function definitions/callsGui Andrade
The `noundef` attribute indicates an argument or return value which may never have an undef value representation. This patch allows LLVM to parse the attribute. Differential Revision: https://reviews.llvm.org/D83412
2020-07-07[NFC] Adding the align attribute on Atomic{CmpXchg|RMW}InstGuillaume Chatelet
This is the first step to add support for the align attribute to AtomicRMWInst and AtomicCmpXchgInst. Next step is to add support in IRBuilder and BitcodeReader. Bug: https://bugs.llvm.org/show_bug.cgi?id=27168 Differential Revision: https://reviews.llvm.org/D83136
2020-06-30[BitcodeReader] Fix DelayedShuffle handling for ConstantExpr shuffles.Eli Friedman
The indexing was messed up, so the result was completely broken. Shuffle constant exprs are rare in practice; without vscale types, constant folding generally elminates them. So sort of hard to trip over. Fixes regression from D72467. (Recommitting after fix for memory leak.) Differential Revision: https://reviews.llvm.org/D80330
generated by cgit v1.2.3 (git 2.25.1) at 2026-06-30 08:32:27 +0000