summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Reader
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] Fix trivial typos in commentsJames Henderson2020-01-061-1/+1
| | | | | | | | Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72143 Patch by Kazuaki Ishizaki.
* Revert "DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode ↵David Blaikie2019-12-301-1/+1
| | | | | | | | | | | | serialization/deserialization" Seeing some curious CFI failures internally - which makes little sense to me, as I don't think anyone is using this flag (even us, internally)... so sounds like a bug in my code somewhere (possibly a latent one that propagating this flag exposed, not sure). Reverting while I investigate. This reverts commit c51b45e32ef7f35c11891f60871aa9c2c04cd991.
* Ignore "no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" in favor ↵Fangrui Song2019-12-301-0/+1
| | | | | | | | | | | | | 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
* DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode ↵David Blaikie2019-12-271-1/+1
| | | | | | serialization/deserialization Follow-up to r346788 review feedback from Adrian Prantl.
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* Fix error message missed in commit dde589389fcb8b5098f7a47f1b781b27d29a0cac.Andrew Browne2019-11-181-2/+4
| | | | | | | | | | | | | | 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
* [IR] Redefine Freeze instructionaqjune2019-11-121-4/+20
| | | | | | | | | | | | | | | | | | | | 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
* ThinLTO : Import always_inline functions irrespective of the thresholdTeresa Johnson2019-11-081-0/+1
| | | | | | | | | | | | | | | | 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
* [ThinLTO] Import readonly vars with refsevgeny2019-11-071-3/+7
| | | | | | Patch allows importing declarations of functions and variables, referenced by the initializer of some other readonly variable. Differential revision: https://reviews.llvm.org/D69561
* [IR] Add Freeze instructionaqjune2019-11-051-7/+4
| | | | | | | | | | | | | | | | | | 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
* [BitcodeReader] Fixed use after move warnings. NFCI.Dávid Bolvanský2019-11-031-10/+0
|
* [BitcodeReader] Fixed null check after dereferencing warning. NFCI.Dávid Bolvanský2019-11-031-1/+1
|
* [BitcodeReader] Fixed null pointer dereferencing warning. NFCI.Dávid Bolvanský2019-11-031-0/+1
|
* [IR] Allow fast math flags on calls with floating point array type.Jay Foad2019-10-301-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Alignment][NFC] Convert AllocaInst to MaybeAlignGuillaume Chatelet2019-10-251-1/+1
| | | | | | | | | | | | | | | | | 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
* [Alignment][NFC] Convert StoreInst to MaybeAlignGuillaume Chatelet2019-10-221-4/+2
| | | | | | | | | | | | | | | | | 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
* [Alignment][NFC] Convert LoadInst to MaybeAlignGuillaume Chatelet2019-10-221-4/+2
| | | | | | | | | | | | | | | | | 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
* [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet2019-10-151-15/+19
| | | | | | | | | | | | | | | | | 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
* Add FMF to vector ops for phiMichael Berg2019-10-141-1/+1
| | | | | | | | | | | | | | 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
* [Bitcode] Update naming of UNOP_NEG to UNOP_FNEGCameron McInally2019-10-071-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D68588 llvm-svn: 373958
* MetadataLoader upgradeCUVariables() - silence static analyzer ↵Simon Pilgrim2019-10-021-1/+1
| | | | | | | | dyn_cast_or_null<> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we know that the source won't be null so just use dyn_cast, which will assert if the value somehow is actually null. llvm-svn: 373448
* MetadataLoader lazyLoadOneMetadata - silence static analyzer ↵Simon Pilgrim2019-09-261-1/+1
| | | | | | | | dyn_cast<MDNode> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<MDNode> directly and if not assert will fire for us. llvm-svn: 372966
* [IR] allow fast-math-flags on phi of FP values (2nd try)Sanjay Patel2019-09-251-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert [IR] allow fast-math-flags on phi of FP valuesSanjay Patel2019-09-251-23/+6
| | | | | | This reverts r372866 (git commit dec03223a97af0e4dfcb23da55c0f7f8c9b62d00) llvm-svn: 372868
* [IR] allow fast-math-flags on phi of FP valuesSanjay Patel2019-09-251-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The changes here are based on the corresponding diffs for allowing FMF on 'select': 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: 372866
* Add AutoUpgrade function to add new address space datalayout string to ↵Amy Huang2019-09-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | existing datalayouts. Summary: Add function to AutoUpgrade to change the datalayout of old X86 datalayout strings. This adds "-p270:32:32-p271:32:32-p272:64:64" to X86 datalayouts that are otherwise valid and don't already contain it. This also removes the compatibility changes in https://reviews.llvm.org/D66843. Datalayout change in https://reviews.llvm.org/D64931. Reviewers: rnk, echristo Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67631 llvm-svn: 372267
* [BitcodeReader] Check if we can create a null constant for type.Florian Hahn2019-08-211-0/+2
| | | | | | | | | | | | | | | | | | | We cannot create null constants for certain types, e.g. VoidTy, FunctionTy or LabelTy. getNullValue asserts if we pass in an unsupported type. We should also check for opaque types, but I'm not sure how. This fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14795. Reviewers: t.p.northover, jfb, vsk Reviewed By: vsk Tags: #llvm Differential Revision: https://reviews.llvm.org/D65897 llvm-svn: 369557
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-152-10/+10
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [AutoUpgrader] Make ArcRuntime Autoupgrader more conservativeSteven Wu2019-08-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a tweak to r368311 and r368646 which auto upgrades the calls to objc runtime functions to objc runtime intrinsics, in order to make sure that the auto upgrader does not trigger with up-to-date bitcode. It is possible for bitcode that is up-to-date to contain direct calls to objc runtime function and those are not inserted by compiler as part of ARC and they should not be upgraded. Now auto upgrader only triggers as when the old style of ARC marker is used so it is guaranteed that it won't trigger on update-to-date bitcode. This also means it won't do this upgrade for bitcode from llvm-8 and llvm-9, which preserves the behavior of those releases. Ideally they should be upgraded as well but it is more important to make sure AutoUpgrader will not trigger on up-to-date bitcode. Reviewers: ahatanak, rjmccall, dexonsmith, pete Reviewed By: dexonsmith Subscribers: hiraditya, jkorous, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66153 llvm-svn: 368730
* [ObjC][ARC] Upgrade calls to ARC runtime functions to intrinsic calls ifAkira Hatanaka2019-08-081-0/+1
| | | | | | | | | | | | | | | | | | | | | the bitcode has the arm64 retainAutoreleasedReturnValue marker The ARC middle-end passes stopped optimizing or transforming bitcode that has been compiled with old compilers after we started emitting calls to ARC runtime functions as intrinsic calls instead of normal function calls in the front-end and made changes to teach the ARC middle-end passes about those intrinsics (see r349534). This patch converts calls to ARC runtime functions that are not intrinsic functions to intrinsic function calls if the bitcode has the arm64 retainAutoreleasedReturnValue marker. Checking for the presence of the marker is necessary to make sure we aren't changing ARC function calls that were originally MRR message sends (see r349952). rdar://problem/53280660 Differential Revision: https://reviews.llvm.org/D65902 llvm-svn: 368311
* Reland: [Remarks] Add an LLVM-bitstream-based remark serializerFrancis Visoiu Mistrih2019-07-311-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new serializer, using a binary format based on the LLVM bitstream format. This format provides a way to serialize the remarks in two modes: 1) Separate mode: the metadata is separate from the remark entries. 2) Standalone mode: the metadata and the remark entries are in the same file. The format contains: * a meta block: container version, container type, string table, external file path, remark version * a remark block: type, remark name, pass name, function name, debug file, debug line, debug column, hotness, arguments (key, value, debug file, debug line, debug column) A string table is required for this format, which will be dumped in the meta block to be consumed before parsing the remark blocks. On clang itself, we noticed a size reduction of 13.4x compared to YAML, and a compile-time reduction of between 1.7% and 3.5% on CTMark. Differential Revision: https://reviews.llvm.org/D63466 Original llvm-svn: 367364 Revert llvm-svn: 367370 llvm-svn: 367372
* Revert "[Remarks] Add an LLVM-bitstream-based remark serializer"Francis Visoiu Mistrih2019-07-311-10/+0
| | | | | | | | This reverts commit r367364. Breaks some bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/3161/steps/annotate/logs/stdio llvm-svn: 367370
* [Remarks] Add an LLVM-bitstream-based remark serializerFrancis Visoiu Mistrih2019-07-301-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new serializer, using a binary format based on the LLVM bitstream format. This format provides a way to serialize the remarks in two modes: 1) Separate mode: the metadata is separate from the remark entries. 2) Standalone mode: the metadata and the remark entries are in the same file. The format contains: * a meta block: container version, container type, string table, external file path, remark version * a remark block: type, remark name, pass name, function name, debug file, debug line, debug column, hotness, arguments (key, value, debug file, debug line, debug column) A string table is required for this format, which will be dumped in the meta block to be consumed before parsing the remark blocks. On clang itself, we noticed a size reduction of 13.4x compared to YAML, and a compile-time reduction of between 1.7% and 3.5% on CTMark. Differential Revision: https://reviews.llvm.org/D63466 llvm-svn: 367364
* [llvm-bcanalyzer] Fixed error 'Expected<T> must be checked before access or ↵Denis Bakhvalov2019-07-171-2/+5
| | | | | | | | | | | | | | | | destruction' After rL365286 I had failing test: LLVM :: tools/gold/X86/v1.12/thinlto_emit_linked_objects.ll It was failing with the output: $ llvm-bcanalyzer --dump llvm/test/tools/gold/X86/v1.12/Output/thinlto_emit_linked_objects.ll.tmp3.o.thinlto.bc Expected<T> must be checked before access or destruction. Unchecked Expected<T> contained error: Unexpected end of file reading 0 of 0 bytesStack dump: Change-Id: I07e03262074ea5e0aae7a8d787d5487c87f914a2 llvm-svn: 366387
* ARM MTE stack sanitizer.Evgeniy Stepanov2019-07-151-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Add "memtag" sanitizer that detects and mitigates stack memory issues using armv8.5 Memory Tagging Extension. It is similar in principle to HWASan, which is a software implementation of the same idea, but there are enough differencies to warrant a new sanitizer type IMHO. It is also expected to have very different performance properties. The new sanitizer does not have a runtime library (it may grow one later, along with a "debugging" mode). Similar to SafeStack and StackProtector, the instrumentation pass (in a follow up change) will be inserted in all cases, but will only affect functions marked with the new sanitize_memtag attribute. Reviewers: pcc, hctim, vitalybuka, ostannard Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64169 llvm-svn: 366123
* Recommit "[BitcodeReader] Validate OpNum, before accessing Record array."Florian Hahn2019-07-141-0/+4
| | | | | | | | | | | | | | | | | | | | | This recommits r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164) Original message: Currently invalid bitcode files can cause a crash, when OpNum exceeds the number of elements in Record, like in the attached bitcode file. The test case was generated by clusterfuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15698 Reviewers: t.p.northover, thegameg, jfb Reviewed By: jfb Differential Revision: https://reviews.llvm.org/D64507 llvm-svn: 365750jkkkk llvm-svn: 366018
* [BitcodeReader] Use tighter upper bound to validate forward references.Florian Hahn2019-07-144-8/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | At the moment, bitcode files with invalid forward reference can easily cause the bitcode reader to run out of memory, by creating a forward reference with a very high index. We can use the size of the bitcode file as an upper bound, because a valid bitcode file can never contain more records. This should be sufficient to fail early in most cases. The only exception is large files with invalid forward references close to the file size. There are a couple of clusterfuzz runs that fail with out-of-memory because of very high forward references and they should be fixed by this patch. A concrete example for this is D64507, which causes out-of-memory on systems with low memory, like the hexagon upstream bots. Reviewers: t.p.northover, thegameg, jfb, efriedma, hfinkel Reviewed By: jfb Differential Revision: https://reviews.llvm.org/D64577 llvm-svn: 366017
* [Attributor] Deduce "nosync" function attribute.Stefan Stipanovic2019-07-111-1/+7
| | | | | | | | | | | | | | Introduce and deduce "nosync" function attribute to indicate that a function does not synchronize with another thread in a way that other thread might free memory. Reviewers: jdoerfert, jfb, nhaehnle, arsenm Subscribers: wdng, hfinkel, nhaenhle, mehdi_amini, steven_wu, dexonsmith, arsenm, uenoku, hiraditya, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D62766 llvm-svn: 365830
* Revert [BitcodeReader] Validate OpNum, before accessing Record array.Florian Hahn2019-07-111-4/+0
| | | | | | | | | | | | This reverts r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164) llvm-dis runs out of memory while opening invalid-fcmp-opnum.bc on llvm-hexagon-elf, probably because the bitcode file contains other suspicious values. http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/21949 llvm-svn: 365757
* [BitcodeReader] Validate OpNum, before accessing Record array.Florian Hahn2019-07-111-0/+4
| | | | | | | | | | | | | | | Currently invalid bitcode files can cause a crash, when OpNum exceeds the number of elements in Record, like in the attached bitcode file. The test case was generated by clusterfuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15698 Reviewers: t.p.northover, thegameg, jfb Reviewed By: jfb Differential Revision: https://reviews.llvm.org/D64507 llvm-svn: 365750
* [Bitcode] Explicitly include Bitstream/BitCodes.h and BitstreamWriter.hFrancis Visoiu Mistrih2019-07-091-0/+2
| | | | | | This fixes a modules issue. llvm-svn: 365580
* [Bitcode][NFC] Remove unused variable from BitcodeAnalyzerFrancis Visoiu Mistrih2019-07-081-2/+0
| | | | llvm-svn: 365340
* Add, and infer, a nofree function attributeBrian Homerding2019-07-081-0/+4
| | | | | | | | | | | | This patch adds a function attribute, nofree, to indicate that a function does not, directly or indirectly, call a memory-deallocation function (e.g., free, C++'s operator delete). Reviewers: jdoerfert Differential Revision: https://reviews.llvm.org/D49165 llvm-svn: 365336
* [llvm-bcanalyzer] Refactor and move to libLLVMBitReaderFrancis Visoiu Mistrih2019-07-082-0/+978
| | | | | | | | | | | | | This allows us to use the analyzer from unit tests. * Refactor the interface to use proper error handling for most functions after JF's work. * Move everything into a BitstreamAnalyzer class. * Move that to Bitcode/BitcodeAnalyzer.h. Differential Revision: https://reviews.llvm.org/D64116 llvm-svn: 365286
* [ThinLTO] Attempt to recommit r365188 after alignment fixEugene Leviant2019-07-051-14/+33
| | | | llvm-svn: 365215
* Reverted r365188 due to alignment problems on i686-androidEugene Leviant2019-07-051-33/+14
| | | | llvm-svn: 365206
* Scalable Vector IR Type with further LTO fixesGraham Hunter2019-07-051-2/+4
| | | | | | | | | | | | | | | | | Reintroduces the scalable vector IR type from D32530, after it was reverted a couple of times due to increasing chromium LTO build times. This latest incarnation removes the walk over aggregate types from the verifier entirely, in favor of rejecting scalable vectors in the isValidElementType methods in ArrayType and StructType. This removes the 70% degradation observed with the second repro tarball from PR42210. Reviewers: thakis, hans, rengolin, sdesmalen Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D64079 llvm-svn: 365203
* [ThinLTO] Attempt to recommit r365040 after caching fixEugene Leviant2019-07-051-14/+33
| | | | | | | | | | | | | | It's possible that some function can load and store the same variable using the same constant expression: store %Derived* @foo, %Derived** bitcast (%Base** @bar to %Derived**) %42 = load %Derived*, %Derived** bitcast (%Base** @bar to %Derived**) The bitcast expression was mistakenly cached while processing loads, and never examined later when processing store. This caused @bar to be mistakenly treated as read-only variable. See load-store-caching.ll. llvm-svn: 365188
* Fix -Wdocumentation param warning.Simon Pilgrim2019-07-041-2/+2
| | | | | | Don't put the full stop at the end of a param name - it confuses the doxygen parser llvm-svn: 365128
* Revert [ThinLTO] Optimize writeonly globals outReid Kleckner2019-07-041-33/+14
| | | | | | | | | This reverts r365040 (git commit 5cacb914758c7f436b47c8362100f10cef14bbc4) Speculatively reverting, since this appears to have broken check-lld on Linux. Partial analysis in https://crbug.com/981168. llvm-svn: 365097
OpenPOWER on IntegriCloud