summaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
AgeCommit message (Collapse)Author
2020-06-25Remove references to the 4.0 release as a major breaking (NFC)Mehdi Amini
This is cleaning up comments (mostly in the bitcode handling) about removing some backward compatibility aspect in the 4.0 release. Historically, "4.0" was used during the development of the 3.x versions as "this future major breaking change version". At the time the major number was used to indicate the compatibility. When we reached 3.9 we decided to change the numbering, instead of going to 3.10 we went to 4.0 but after changing the meaning of the major number to not mean anything anymore with respect to bitcode backward compatibility. The current policy (https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility) indicates only now: The current LLVM version supports loading any bitcode since version 3.0. Differential Revision: https://reviews.llvm.org/D82514
2020-06-24Revert "[BitcodeReader] Fix DelayedShuffle handling for ConstantExpr shuffles."Mitch Phillips
Patch has a memory leak bug that broke the ASan buildbots. More info available at: https://reviews.llvm.org/D80330 This reverts commit b5740105d270a2d76da8812cafb63e4b799ada73.
2020-06-23[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. Differential Revision: https://reviews.llvm.org/D80330
2020-06-15[strictfp] Replace dangling strictfp attrs with nobuiltinKevin P. Neal
In preparation for a patch that will enforce new rules for the usage of the strictfp attribute, this patch introduces auto-upgrade behavior that will replace the strictfp attribute on callsites with nobuiltin if the enclosing function declaration doesn't also have the strictfp attribute. This auto-upgrade isn't being performed on .ll files because that would prevent us from writing a test for the forthcoming verifier behavior. Differential Revision: https://reviews.llvm.org/D70096
2020-06-10[StackSafety] Add info into function summaryVitaly Buka
Summary: This patch adds optional field into function summary, implements asm and bitcode serialization. YAML serialization is omitted and can be added later if needed. This patch includes this information into summary only if module contains at least one sanitize_memtag function. In a near future MTE is the user of the analysis. Later if needed we can provede more direct control on when information is included into summary. Reviewers: eugenis Subscribers: hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80908
2020-05-28[ThinLTO] Compute the basic block count across modules.Hiroshi Yamauchi
Summary: Count the per-module number of basic blocks when the module summary is computed and sum them up during Thin LTO indexing. This is used to estimate the working set size under the partial sample PGO. This is split off of D79831. Reviewers: davidxl, espindola Subscribers: emaste, inglorion, hiraditya, MaskRay, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80403
2020-05-21[BitcodeReader] Simplify code. NFCI.Benjamin Kramer
2020-05-16AllocaInst should store Align instead of MaybeAlign.Eli Friedman
Along the lines of D77454 and D79968. Unlike loads and stores, the default alignment is getPrefTypeAlign, to match the existing handling in various places, including SelectionDAG and InstCombine. Differential Revision: https://reviews.llvm.org/D80044
2020-05-16Harden IR and bitcode parsers against infinite size types.Eli Friedman
If isSized is passed a SmallPtrSet, it uses that set to catch infinitely recursive types (for example, a struct that has itself as a member). Otherwise, it just crashes on such types.
2020-05-15StoreInst should store Align, not MaybeAlignEli Friedman
This is D77454, except for stores. All the infrastructure work was done for loads, so the remaining changes necessary are relatively small. Differential Revision: https://reviews.llvm.org/D79968
2020-05-15[IR] Convert null-pointer-is-valid into an enum attributeNikita Popov
The "null-pointer-is-valid" attribute needs to be checked by many pointer-related combines. To make the check more efficient, convert it from a string into an enum attribute. In the future, this attribute may be replaced with data layout properties. Differential Revision: https://reviews.llvm.org/D78862
2020-05-15[IR][BFloat] Add BFloat IR typeTies Stuij
Summary: The BFloat IR type is introduced to provide support for, initially, the BFloat16 datatype introduced with the Armv8.6 architecture (optional from Armv8.2 onwards). It has an 8-bit exponent and a 7-bit mantissa and behaves like an IEEE 754 floating point IR type. This is part of a patch series upstreaming Armv8.6 features. Subsequent patches will upstream intrinsics support and C-lang support for BFloat. Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, sdesmalen, deadalnix, ctetreau Subscribers: hiraditya, llvm-commits, danielkiss, arphaman, kristof.beyls, dexonsmith Tags: #llvm Differential Revision: https://reviews.llvm.org/D78190
2020-05-14Infer alignment of unmarked loads in IR/bitcode parsing.Eli Friedman
For IR generated by a compiler, this is really simple: you just take the datalayout from the beginning of the file, and apply it to all the IR later in the file. For optimization testcases that don't care about the datalayout, this is also really simple: we just use the default datalayout. The complexity here comes from the fact that some LLVM tools allow overriding the datalayout: some tools have an explicit flag for this, some tools will infer a datalayout based on the code generation target. Supporting this properly required plumbing through a bunch of new machinery: we want to allow overriding the datalayout after the datalayout is parsed from the file, but before we use any information from it. Therefore, IR/bitcode parsing now has a callback to allow tools to compute the datalayout at the appropriate time. Not sure if I covered all the LLVM tools that want to use the callback. (clang? lli? Misc IR manipulation tools like llvm-link?). But this is at least enough for all the LLVM regression tests, and IR without a datalayout is not something frontends should generate. This change had some sort of weird effects for certain CodeGen regression tests: if the datalayout is overridden with a datalayout with a different program or stack address space, we now parse IR based on the overridden datalayout, instead of the one written in the file (or the default one, if none is specified). This broke a few AVR tests, and one AMDGPU test. Outside the CodeGen tests I mentioned, the test changes are all just fixing CHECK lines and moving around datalayout lines in weird places. Differential Revision: https://reviews.llvm.org/D78403
2020-05-14[BitcodeReader] datalayout must be specified before it is queried.Eli Friedman
This isn't really a new invariant; it effectively already existed due to existing DataLayout queries. But this makes it explicit. This is technically not backward-compatible with the existing bitcode reader, but it's backward-compatible with the output of the bitcode writer, which is what matters in practice. No testcase because I don't know a good way to write one: there are no existing tools that can generate a bitcode file that would trigger the error. Split off from D78403. Differential Revision: https://reviews.llvm.org/D79900
2020-05-12Add nomerge function attribute to supress tail merge optimization in simplifyCFGZequan Wu
We want to add a way to avoid merging identical calls so as to keep the separate debug-information for those calls. There is also an asan usecase where having this attribute would be beneficial to avoid alternative work-arounds. Here is the link to the feature request: https://bugs.llvm.org/show_bug.cgi?id=42783. `nomerge` is different from `noline`. `noinline` prevents function from inlining at callsites, but `nomerge` prevents multiple identical calls from being merged into one. This patch adds `nomerge` to disable the optimization in IR level. A followup patch will be needed to let backend understands `nomerge` and avoid tail merge at backend. Reviewed By: asbirlea, rnk Differential Revision: https://reviews.llvm.org/D78659
2020-04-30[BitcodeReader] Simplify raw attribute handling (NFC)Nikita Popov
Every new attribute we add from now on will not be supported in the raw format, because we ran out of space. Don't bother listing each affected attribute twice.
2020-04-27Add IR constructs for preallocated (inalloca replacement)Arthur Eubanks
Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-04-18[DebugInfo] Change DIEnumerator payload type from int64_t to APIntLemonBoy
This allows the representation of arbitrarily large enumeration values. See https://lists.llvm.org/pipermail/llvm-dev/2017-December/119475.html for context. Reviewed By: andrewrk, aprantl, MaskRay Differential Revision: https://reviews.llvm.org/D62475
2020-04-14[llvm][NFC][CallSite] Remove Implementation uses of CallSiteMircea Trofin
Reviewers: dblaikie, davidxl, craig.topper Subscribers: arsenm, dschuff, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D78142
2020-04-08Clean up usages of asserting vector getters in TypeChristopher Tetreault
Summary: Remove usages of asserting vector getters in Type in preparation for the VectorType refactor. The existence of these functions complicates the refactor while adding little value. Reviewers: espindola, efriedma, sdesmalen Reviewed By: efriedma Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77275
2020-04-06Remove SequentialType from the type heirarchy.Eli Friedman
Now that we have scalable vectors, there's a distinction that isn't getting captured in the original SequentialType: some vectors don't have a known element count, so counting the number of elements doesn't make sense. In some cases, there's a better way to express the commonality using other methods. If we're dealing with GEPs, there's GEP methods; if we're dealing with a ConstantDataSequential, we can query its element type directly. In the relatively few remaining cases, I just decided to write out the type checks. We're talking about relatively few places, and I think the abstraction doesn't really carry its weight. (See thread "[RFC] Refactor class hierarchy of VectorType in the IR" on llvmdev.) Differential Revision: https://reviews.llvm.org/D75661
2020-03-31Remove "mask" operand from shufflevector.Eli Friedman
Instead, represent the mask as out-of-line data in the instruction. This should be more efficient in the places that currently use getShuffleVector(), and paves the way for further changes to add new shuffles for scalable vectors. This doesn't change the syntax in textual IR. And I don't currently plan to change the bitcode encoding in this patch, although we'll probably need to do something once we extend shufflevector for scalable types. I expect that once this is finished, we can then replace the raw "mask" with something more appropriate for scalable vectors. Not sure exactly what this looks like at the moment, but there are a few different ways we could handle it. Maybe we could try to describe specific shuffles. Or maybe we could define it in terms of a function to convert a fixed-length array into an appropriate scalable vector, using a "step", or something like that. Differential Revision: https://reviews.llvm.org/D72467
2020-03-03[NFC] Try fix ubsan buildbot after 876d13378931bee3dcefafff8729c40d5457ff31Tyker
2020-02-18[Assembler] Emit summary index flagsevgeny
Differential revision: https://reviews.llvm.org/D74420
2020-02-10Revert "Remove redundant "std::move"s in return statements"Bill Wendling
The build failed with error: call to deleted constructor of 'llvm::Error' errors. This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.
2020-02-10Remove redundant "std::move"s in return statementsBill Wendling
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-23[ThinLTO] Summarize vcall_visibility metadataTeresa Johnson
Summary: Second patch in series to support Safe Whole Program Devirtualization Enablement, see RFC here: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137543.html Summarize vcall_visibility metadata in ThinLTO global variable summary. Depends on D71907. Reviewers: pcc, evgeny777, steven_wu Subscribers: mehdi_amini, Prazek, inglorion, hiraditya, dexonsmith, arphaman, ostannard, llvm-commits, cfe-commits, davidxl Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71911
2020-01-22[SVE] Pass Scalable argument to VectorType::get in Bitcode ReaderChris Tetreault
Pass the Scalability test to VectorType::get in order to be able to deserialize bitcode that contains scalable vector operations Differential Revision: https://reviews.llvm.org/D73144
2020-01-17Revert "[SVE] Pass Scalable argument to VectorType::get in Bitcode Reader"Eli Friedman
This reverts commit 5df53a22592729e631c4030f38c599b9f37095b7. Caused test failures.
2020-01-17[SVE] Pass Scalable argument to VectorType::get in Bitcode ReaderChristopher Tetreault
Summary: * Pass the Scalability test to VectorType::get in order to be able to deserialize bitcode that contains scalable vector operations Change-Id: I37fe5b1c0c237a9153130deefdc1a6d595c7f12e Reviewers: efriedma, pcc, sdesmalen, apazos, huihuiz, chrisj Reviewed By: sdesmalen Subscribers: tschuett, hiraditya, rkruppe, psnobl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72792
2020-01-15[ThinLTO] Always import constantsevgeny
This patch imports constant variables even when they can't be internalized (which results in promotion). This offers some extra constant folding opportunities. Differential revision: https://reviews.llvm.org/D70404
2019-12-30Ignore "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" in favor ↵Fangrui Song
of "frame-pointer" D56351 (included in LLVM 8.0.0) introduced "frame-pointer". All tests which use "no-frame-pointer-elim" or "no-frame-pointer-elim-non-leaf" have been migrated to use "frame-pointer". Implement UpgradeFramePointerAttributes to upgrade the two obsoleted function attributes for bitcode. Their semantics are ignored. Differential Revision: https://reviews.llvm.org/D71863
2019-11-18Fix error message missed in commit dde589389fcb8b5098f7a47f1b781b27d29a0cac.Andrew Browne
Patch by Andrew Browne <browneee@google.com> Reviewers: tejohnson, evgeny777 Reviewed By: tejohnson Subscribers: arphaman, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70195
2019-11-12[IR] Redefine Freeze instructionaqjune
Summary: This patch redefines freeze instruction from being UnaryOperator to a subclass of UnaryInstruction. ConstantExpr freeze is removed, as discussed in the previous review. FreezeOperator is not added because there's no ConstantExpr freeze. `freeze i8* null` test is added to `test/Bindings/llvm-c/freeze.ll` as well, because the null pointer-related bug in `tools/llvm-c/echo.cpp` is now fixed. InstVisitor has visitFreeze now because freeze is not unaryop anymore. Reviewers: whitequark, deadalnix, craig.topper, jdoerfert, lebedev.ri Reviewed By: craig.topper, lebedev.ri Subscribers: regehr, nlopes, mehdi_amini, hiraditya, steven_wu, dexonsmith, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69932
2019-11-08ThinLTO : Import always_inline functions irrespective of the thresholdTeresa Johnson
Summary: A user can force a function to be inlined by specifying the always_inline attribute. Currently, thinlto implementation is not aware of always_inline functions and does not guarantee import of such functions, which in turn can prevent inlining of such functions. Patch by Bharathi Seshadri <bseshadr@cisco.com> Reviewers: tejohnson Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70014
2019-11-07[ThinLTO] Import readonly vars with refsevgeny
Patch allows importing declarations of functions and variables, referenced by the initializer of some other readonly variable. Differential revision: https://reviews.llvm.org/D69561
2019-11-05[IR] Add Freeze instructionaqjune
Summary: - Define Instruction::Freeze, let it be UnaryOperator - Add support for freeze to LLLexer/LLParser/BitcodeReader/BitcodeWriter The format is `%x = freeze <ty> %v` - Add support for freeze instruction to llvm-c interface. - Add m_Freeze in PatternMatch. - Erase freeze when lowering IR to SelDag. Reviewers: deadalnix, hfinkel, efriedma, lebedev.ri, nlopes, jdoerfert, regehr, filcab, delcypher, whitequark Reviewed By: lebedev.ri, jdoerfert Subscribers: jfb, kristof.beyls, hiraditya, lebedev.ri, steven_wu, dexonsmith, xbolva00, delcypher, spatel, regehr, trentxintong, vsk, filcab, nlopes, mehdi_amini, deadalnix, llvm-commits Differential Revision: https://reviews.llvm.org/D29011
2019-11-03[BitcodeReader] Fixed use after move warnings. NFCI.Dávid Bolvanský
2019-11-03[BitcodeReader] Fixed null check after dereferencing warning. NFCI.Dávid Bolvanský
2019-11-03[BitcodeReader] Fixed null pointer dereferencing warning. NFCI.Dávid Bolvanský
2019-10-30[IR] Allow fast math flags on calls with floating point array type.Jay Foad
Summary: This extends the rules for when a call instruction is deemed to be an FPMathOperator, which is based on the type of the call (i.e. the return type of the function being called). Previously we only allowed floating-point and vector-of-floating-point types. Now we also allow arrays (nested to any depth) of floating-point and vector-of-floating-point types. This was motivated by llpc, the pipeline compiler for AMD GPUs (https://github.com/GPUOpen-Drivers/llpc). llpc has many math library functions that operate on vectors, typically represented as <4 x float>, and some that operate on matrices, typically represented as [4 x <4 x float>], and it's useful to be able to decorate calls to all of them with fast math flags. Reviewers: spatel, wristow, arsenm, hfinkel, aemerson, efriedma, cameron.mcinally, mcberg2017, jmolloy Subscribers: wdng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69161
2019-10-25[Alignment][NFC] Convert AllocaInst to MaybeAlignGuillaume Chatelet
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Reviewed By: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69301
2019-10-22[Alignment][NFC] Convert StoreInst to MaybeAlignGuillaume Chatelet
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69303 llvm-svn: 375499
2019-10-22[Alignment][NFC] Convert LoadInst to MaybeAlignGuillaume Chatelet
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69302 llvm-svn: 375498
2019-10-15[Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68944 llvm-svn: 374880
2019-10-14Add FMF to vector ops for phiMichael Berg
Summary: Small amendment to handle vector cases for D67564. Reviewers: spatel, eli.friedman, hfinkel, cameron.mcinally, arsenm, jmolloy, bogner Reviewed By: cameron.mcinally, bogner Subscribers: llvm-commits, efriedma, reames, bogner, wdng Differential Revision: https://reviews.llvm.org/D68748 llvm-svn: 374794
2019-10-07[Bitcode] Update naming of UNOP_NEG to UNOP_FNEGCameron McInally
Differential Revision: https://reviews.llvm.org/D68588 llvm-svn: 373958
2019-09-25[IR] allow fast-math-flags on phi of FP values (2nd try)Sanjay Patel
The changes here are based on the corresponding diffs for allowing FMF on 'select': D61917 <https://reviews.llvm.org/D61917> As discussed there, we want to have fast-math-flags be a property of an FP value because the alternative (having them on things like fcmp) leads to logical inconsistency such as: https://bugs.llvm.org/show_bug.cgi?id=38086 The earlier patch for select made almost no practical difference because most unoptimized conditional code begins life as a phi (based on what I see in clang). Similarly, I don't expect this patch to do much on its own either because SimplifyCFG promptly drops the flags when converting to select on a minimal example like: https://bugs.llvm.org/show_bug.cgi?id=39535 But once we have this plumbing in place, we should be able to wire up the FMF propagation and start solving cases like that. The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a regression in a LoopVectorize test. We are intersecting the FMF of any FPMathOperator there, so if a phi is not properly annotated, new math instructions may not be either. Once we fix the propagation in SimplifyCFG, it may be safe to remove that hack. Differential Revision: https://reviews.llvm.org/D67564 llvm-svn: 372878
2019-09-25Revert [IR] allow fast-math-flags on phi of FP valuesSanjay Patel
This reverts r372866 (git commit dec03223a97af0e4dfcb23da55c0f7f8c9b62d00) llvm-svn: 372868
generated by cgit v1.2.3 (git 2.25.1) at 2026-06-30 19:45:01 +0000