summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
...
* [ADT] Removed VariadicFunctionDmitri Gribenko2019-08-302-110/+0
| | | | | | | | | | | | | | | Summary: It is not used. It uses macro-based unrolling instead of variadic templates, so it is not idiomatic anymore, and therefore it is a questionable API to keep "just in case". Subscribers: mgorny, dmgreen, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66961 llvm-svn: 370441
* GlobalISel: Add maskedValueIsZero and signBitIsZero to known bitsMatt Arsenault2019-08-291-0/+16
| | | | | | | I dropped the DemandedElts since it seems to be missing from some of the new interfaces, but not others. llvm-svn: 370389
* Fix for "DICompileUnit not listed in llvm.dbg.cu" verification error after ...Artur Pilipenko2019-08-281-0/+56
| | | | | | | | | | | | | | | | | | | ...cloning a function from a different module Currently when a function with debug info is cloned from a different module, the cloned function may have hanging DICompileUnits, so that the module with the cloned function fails debug info verification. The proposed fix inserts all DICompileUnits reachable from the cloned function to "llvm.dbg.cu" metadata operands of the cloned function module. Reviewed By: aprantl, efriedma Differential Revision: https://reviews.llvm.org/D66510 Patch by Oleg Pliss (Oleg.Pliss@azul.com) llvm-svn: 370265
* [IntrinsicEmitter] Support scalable vectors in intrinsicsCullen Rhodes2019-08-271-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for scalable vectors in intrinsics, enabling intrinsics such as the following to be defined: declare <vscale x 4 x i32> @llvm.something.nxv4i32(<vscale x 4 x i32>) Support for this is implemented by defining a new type descriptor for scalable vectors and adding mangling support for scalable vector types in the name mangling scheme used by 'any' types in intrinsic signatures. Tests have been added for IRBuilder to test scalable vectors work as expected when using intrinsics through this interface. This required implementing an intrinsic that is explicitly defined with scalable vectors, e.g. LLVMType<nxv4i32>, an SVE floating-point convert intrinsic was used for this. The behaviour of the overloaded type LLVMScalarOrSameVectorWidth with scalable vectors is tested using the existing masked load intrinsic. Also added an .ll test to test the Verifier catches a bad intrinsic argument when passing a fixed-width predicate (mask) to the masked.load intrinsic where a scalable is expected. Patch by Paul Walker Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D65930 llvm-svn: 370053
* Add error handling to the DataExtractor classPavel Labath2019-08-271-0/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is motivated by D63591, where we realized that there isn't a really good way of telling whether a DataExtractor is reading actual data, or is it just returning default values because it reached the end of the buffer. This patch resolves that by providing a new "Cursor" class. A Cursor object encapsulates two things: - the current position/offset in the DataExtractor - an error object Storing the error object inside the Cursor enables one to use the same pattern as the std::{io}stream API, where one can blindly perform a sequence of reads and only check for errors once at the end of the operation. Similarly to the stream API, as soon as we encounter one error, all of the subsequent operations are skipped (return default values) too, even if the would suceed with clear error state. Unlike the std::stream API (but in line with other llvm APIs), we force the error state to be checked through usage of llvm::Error. Reviewers: probinson, dblaikie, JDevlieghere, aprantl, echristo Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63713 llvm-svn: 370042
* [ORC] Make sure that queries on emitted-but-not-ready symbols fail correctly.Lang Hames2019-08-261-0/+54
| | | | | | | | | | | | | | | | | In r369808 the failure scheme for ORC symbols was changed to make MaterializationResponsibility objects responsible for failing the symbols they represented. This simplifies error logic in the case where symbols are still covered by a MaterializationResponsibility, but left a gap in error handling: Symbols that have been emitted but are not yet ready (due to a dependence on some unemitted symbol) are not covered by a MaterializationResponsibility object. Under the scheme introduced in r369808 such symbols would be moved to the error state, but queries on those symbols were never notified. This led to deadlocks when such symbols were failed. This commit updates error logic to immediately fail queries on any symbol that has already been emitted if one of its dependencies fails. llvm-svn: 369976
* [ORC] Fix an overly aggressive assert.Lang Hames2019-08-261-0/+29
| | | | | | | | Symbols that have not been queried will not have MaterializingInfo entries, so remove the assert that all failed symbols should have these entries. Also updates the loop to only remove entries that were found earlier. llvm-svn: 369975
* [ADT] Make StringRef(const char*) constexprBenjamin Kramer2019-08-262-1/+4
| | | | | | | | | | This should let us get rid of StringLiteral in the long term and avoid chasing accidental StringRef globals once and for all. This requires C++14, I godbolted it on every compiler I know we support so I hope there won't be much fallout. llvm-svn: 369961
* [ORC] Remove query dependencies when symbols are resolved.Lang Hames2019-08-231-1/+25
| | | | | | | | | | If the dependencies are not removed then a late failure (one symbol covered by the query failing after others have already been resolved) can result in an attempt to detach the query from already finalized symbol, resulting in an assert/crash. This patch fixes the issue by removing query dependencies in JITDylib::resolve for symbols that meet the required state. llvm-svn: 369809
* [ORC] Fix a FIXME: Propagate errors to dependencies.Lang Hames2019-08-232-52/+255
| | | | | | | | | | | | | When symbols are failed (via MaterializationResponsibility::failMaterialization) any symbols depending on them will now be moved to an error state. Attempting to resolve or emit a symbol in the error state (via the notifyResolved or notifyEmitted methods on MaterializationResponsibility) will result in an error. If notifyResolved or notifyEmitted return an error due to failure of a dependence then the caller should log or discard the error and call failMaterialization to propagate the failure to any queries waiting on the symbols being resolved/emitted (plus their dependencies). llvm-svn: 369808
* [SampleFDO] Add ExtBinary format to support extension of binary profile.Wei Mi2019-08-231-0/+8
| | | | | | | | | | | | This is a patch split from https://reviews.llvm.org/D66374. It tries to add a new format of profile called ExtBinary. The format adds a section header table to the profile and organize the profile in sections, so the future extension like adding a new section or extending an existing section will be easier while keeping backward compatiblity feasible. Differential Revision: https://reviews.llvm.org/D66513 llvm-svn: 369798
* [Support] Improve readNativeFile(Slice) interfacePavel Labath2019-08-222-16/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was a subtle, but pretty important difference between the Slice and regular versions of this function. The Slice function was zero-initializing the rest of the buffer when the read syscall returned less bytes than expected, while the regular function did not. This patch removes the inconsistency by making both functions *not* zero-initialize the buffer. The zeroing code is moved to the MemoryBuffer class, which is currently the only user of this code. This makes the API more consistent, and the code shorter. While in there, I also refactor the functions to return the number of bytes through the regular return value (via Expected<size_t>) instead of a separate by-ref argument. Reviewers: aganea, rnk Subscribers: kristina, Bigcheese, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66471 llvm-svn: 369627
* Add FileWriter to GSYM and encode/decode functions to AddressRange and ↵Greg Clayton2019-08-211-1/+119
| | | | | | | | | | | | | | | | AddressRanges The full GSYM patch started with: https://reviews.llvm.org/D53379 This patch add the ability to encode data using the new llvm::gsym::FileWriter class. FileWriter is a simplified binary data writer class that doesn't require targets, target definitions, architectures, or require any other optional compile time libraries to be enabled via the build process. This class needs the ability to seek to different spots in the binary data that it produces to fix up offsets and sizes in GSYM data. It currently uses std::ostream over llvm::raw_ostream because llvm::raw_ostream doesn't support seeking which is required when encoding and decoding GSYM data. AddressRange objects are encoded and decoded to be relative to a base address. This will be the FunctionInfo's start address if the AddressRange is directly contained in a FunctionInfo, or a base address of the containing parent AddressRange or AddressRanges. This allows address ranges to be efficiently encoded using ULEB128 encodings as we encode the offset and size of each range instead of full addresses. This also makes encoded addresses easy to relocate as we just need to relocate one base address. Differential Revision: https://reviews.llvm.org/D63828 llvm-svn: 369587
* [BinaryFormat] Teach identify_magic about Tapi files.Cyndy Ishida2019-08-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Tapi files are YAML files that start with the !tapi tag. The only execption are TBD v1 files, which don't have a tag. In that case we have to scan a little further and check if the first key "archs" exists. This is the first patch in a series of patches to add libObject support for text-based dynamic library (.tbd) files. This patch is practically exactly the same as D37820, that was never pushed to master, and is needed for future commits related to reading tbd files for llvm-nm Reviewers: ributzka, steven_wu, bollu, espindola, jfb, shafik, jdoerfert Reviewed By: steven_wu Subscribers: dexonsmith, llvm-commits Tags: #llvm, #clang, #sanitizers, #lldb, #libc, #openmp Differential Revision: https://reviews.llvm.org/D66149 llvm-svn: 369579
* reland [gtest] Fix printing of StringRef and SmallString in assert messages.Sam McCall2019-08-212-1/+15
| | | | | | | | | Renames GTEST_NO_LLVM_RAW_OSTREAM -> GTEST_NO_LLVM_SUPPORT and guards the new features behind it. This reverts commit a063bcf3ef5a879adbe9639a3c187d876eee0e66. llvm-svn: 369527
* Revert "[gtest] Fix printing of StringRef and SmallString in assert messages."Sam McCall2019-08-212-15/+1
| | | | | | This reverts commit 4becb2ab4e9f52ce98272d1f5930d6942af5172b. llvm-svn: 369525
* [gtest] Fix printing of StringRef and SmallString in assert messages.Sam McCall2019-08-212-1/+15
| | | | | | | | | | | | | | | | | | Summary: These are detected by gtest as containers, and so previously printed as e.g. { '.' (46, 0x2E), 's' (115, 0x73), 'e' (101, 0x65), 'c' (99, 0x63), '0' (48, 0x30) }, gtest itself overloads PrintTo for std::string and friends, we use the same mechanism. Reviewers: labath Subscribers: dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66520 llvm-svn: 369518
* MinidumpYAML: move serialization code to MinidumpEmitter.cppPavel Labath2019-08-211-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The code for serializing minidumps was living in MinidumpYAML.cpp so that it would be accessible from unit tests. While this had its advantages, it was also unfortunate because it broke symmetry with all other yaml2obj serializers. Fortunately, nowadays all of yaml2obj is a library, so we don't need to do anything special. This patch improves the code consistency by moving the serialization code to MinidumpEmitter.cpp to match the style used in other backends. It also removes the writeAsBinary entry point in favor of the more general convertYAML interface. This patch is just massaging the code a bit. There shouldn't be any functional change here. Reviewers: jhenderson, abrachet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66474 llvm-svn: 369517
* Add TinyPtrVector support for general pointer-like things.Andrew Trick2019-08-202-9/+71
| | | | | | | | | | | | | | | In particular, make TinyPtrVector<PtrIntPair<T *, 1>> work. Remove all unnecessary assumptions that the element type has a formal "null" representation. The important property to maintain is that default-constructed element type has the same internal representation as the default-constructed PointerUnion (all zero bits). Remove the incorrect recursive behavior from PointerUnion::isNull. This was never generally correct because it only recursed over the first type parameter. With variadic templates it's completely unnecessary. llvm-svn: 369473
* Recommit "MemoryBuffer: Add a missing error-check to getOpenFileImpl"Pavel Labath2019-08-201-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | This recommits r368977, which was reverted in r369027 due to test failures in lldb. The cause of this was different behavior of readNativeFileSlice on windows and unix. These have been addressed in r369269. The original commit message was: In case the function was called with a desired read size *and* the file was not an "mmap()" candidate, the function was falling back to a "pread()", but it was failing to check the result of that system call. This meant that the function would return "success" even though the read operation failed, and it returned a buffer full of uninitialized memory. Reviewers: rnk, dblaikie Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66224 llvm-svn: 369370
* [cmake] Link in LLVMPasses due to dependency by LLVMOrcJIT; NFCHubert Tong2019-08-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: rL367756 (f5c40cb) increases the dependency of LLVMOrcJIT on LLVMPasses. In particular, symbols defined in LLVMPasses that are referenced by the destructor of `PassBuilder` are now referenced by LLVMOrcJIT through `Speculation.cpp.o`. We believe that referencing symbols defined in LLVMPasses in the destructor of `PassBuilder` is valid, and that adding to the set of such symbols is legitimate. To support such cases, this patch adds LLVMPasses to the set of libraries being linked when linking in LLVMOrcJIT causes such symbols from LLVMPasses to be referenced. Reviewers: Whitney, anhtuyen, pree-jackie Reviewed By: pree-jackie Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66441 llvm-svn: 369310
* Filesystem/Windows: fix inconsistency in readNativeFileSlice APIPavel Labath2019-08-191-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The windows version implementation of readNativeFileSlice, was trying to match the POSIX behavior of not treating EOF as an error, but it was only handling the case of reading from a pipe. Attempting to read past the end of a regular file returns a slightly different error code, which needs to be handled too. This patch adds ERROR_HANDLE_EOF to the list of error codes to be treated as an end of file, and adds some unit tests for the API. This issue was found while attempting to land D66224, which caused a bunch of lldb tests to start failing on windows. Reviewers: rnk, aganea Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66344 llvm-svn: 369269
* [ORC] Re-introduce self-dependence accidentally dropped from a unit test.Lang Hames2019-08-161-0/+1
| | | | llvm-svn: 369171
* [ADT] Remove llvm::make_unique utility.Jonas Devlieghere2019-08-161-1/+1
| | | | | | | | | | All uses of llvm::make_unique should have been replaced with std::make_unique. This patch represents the last part of the migration and removes the utility from LLVM. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 369130
* [TextAPI] Update reader to be supported by lib/ObjectCyndy Ishida2019-08-163-115/+98
| | | | | | | | | | | | | | | | | | | Summary: To be able to use the TextAPI/Reader for tbd file consumption (by libObject) it gets passed a MemoryBufferRef which isn't castable to MemoryBuffer. Updated the tests to expect that input as well. Reviewers: ributzka, steven_wu Reviewed By: steven_wu Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66147 llvm-svn: 369119
* Revert "MemoryBuffer: Add a missing error-check to getOpenFileImpl"Pavel Labath2019-08-151-51/+0
| | | | | | This reverts commit r368977 because it broke a couple of tests in lldb. llvm-svn: 369027
* [LLVM][Alignment] Fix MSVC potential division by 0 warning (PR42911)Simon Pilgrim2019-08-151-0/+10
| | | | | | | | Original Patch by @gchatelet (Guillaume Chatelet) Differential Revision: https://reviews.llvm.org/D65859 llvm-svn: 369016
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1544-177/+177
| | | | | | | | 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
* Revert rL368939 "Remove LVALUE / RVALUE workarounds"Russell Gallop2019-08-151-0/+4
| | | | | | | | This reverts commit cad8356d699b36c73abb267f65db575ddacbd652. To unbreak Windows bots llvm-svn: 368985
* MemoryBuffer: Add a missing error-check to getOpenFileImplPavel Labath2019-08-151-0/+51
| | | | | | | | | | | | | | | | | | | Summary: In case the function was called with a desired read size *and* the file was not an "mmap()" candidate, the function was falling back to a "pread()", but it was failing to check the result of that system call. This meant that the function would return "success" even though the read operation failed, and it returned a buffer full of uninitialized memory. Reviewers: rnk, dblaikie Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66224 llvm-svn: 368977
* Remove LVALUE / RVALUE workaroundsJF Bastien2019-08-141-4/+0
| | | | | | | | | | | | Summary: LLVM_HAS_RVALUE_REFERENCE_THIS and LLVM_LVALUE_FUNCTION shouldn't be needed anymore because the minimum compiler versions support them. Subscribers: jkorous, dexonsmith, cfe-commits, llvm-commits, hans, thakis, chandlerc, rnk Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D66240 llvm-svn: 368939
* Revert "raw_ostream: add operator<< overload for std::error_code"Pavel Labath2019-08-148-18/+78
| | | | | | | | | | | This reverts commit r368849, because it breaks some bots (e.g. llvm-clang-x86_64-win-fast). It turns out this is not as NFC as we had hoped, because operator== will consider two std::error_codes to be distinct even though they both hold "success" values if they have different categories. llvm-svn: 368854
* raw_ostream: add operator<< overload for std::error_codePavel Labath2019-08-148-78/+18
| | | | | | | | | | | | | | | | | | | | | | | Summary: The main motivation for this is unit tests, which contain a large macro for pretty-printing std::error_code, and this macro is duplicated in every file that needs to do this. However, the functionality may be useful elsewhere too. In this patch I have reimplemented the existing ASSERT_NO_ERROR macros to reuse the new functionality, but I have kept the macro (as a one-liner) as it is slightly more readable than ASSERT_EQ(..., std::error_code()). Reviewers: sammccall, ilya-biryukov Subscribers: zturner, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65643 llvm-svn: 368849
* [ORC] Refactor definition-generation, add a generator for static libraries.Lang Hames2019-08-131-8/+28
| | | | | | | | | | | | | | | | | This patch replaces the JITDylib::DefinitionGenerator typedef with a class of the same name, and adds support for attaching a sequence of DefinitionGeneration objects to a JITDylib. This patch also adds a new definition generator, StaticLibraryDefinitionGenerator, that can be used to add symbols fom a static library to a JITDylib. An object from the static library will be added (via a supplied ObjectLayer reference) whenever a symbol from that object is referenced. To enable testing, lli is updated to add support for the --extra-archive option when running in -jit-kind=orc-lazy mode. llvm-svn: 368707
* Added unit tests to check supported rounding modesSerge Pavlov2019-08-131-0/+28
| | | | | | | | Also added fixed misspelled metadata name. Differential Revision: https://reviews.llvm.org/D66073 llvm-svn: 368650
* [GlobalISel]: Add KnownBits for G_XORAditya Nandakumar2019-08-131-0/+16
| | | | | | https://reviews.llvm.org/D66119 llvm-svn: 368648
* [TextAPI] Fix & Add tests for tbd files version 3.Juergen Ributzka2019-08-122-1/+438
| | | | | | | | | | | | - There was a simple typo in TextStub code that prevented version 3 files to be read. - Included a version 3 unit test to handle the differences in the format. - Also a typo in Error.h inside the comments. https://reviews.llvm.org/D66041 This patch is from Cyndy Ishida <cyndy_ishida@apple.com>. llvm-svn: 368630
* [GISel]: Fix a bug in KnownBits where we should have been using SizeInBitsAditya Nandakumar2019-08-121-0/+16
| | | | | | | | | https://reviews.llvm.org/D66039 We were using getIndexSize instead of getIndexSizeInBits(). Added test case for G_PTRTOINT and G_INTTOPTR. llvm-svn: 368618
* Revert "Disable MachO TBD write tests for Windows."Juergen Ributzka2019-08-122-6/+0
| | | | | | The underlying issue was fixed in r357759. llvm-svn: 368611
* Remove leftover MF->dump()'s from r368487 that break release buildsDaniel Sanders2019-08-091-4/+0
| | | | llvm-svn: 368489
* [globalisel] Add G_SEXT_INREGDaniel Sanders2019-08-092-0/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Targets often have instructions that can sign-extend certain cases faster than the equivalent shift-left/arithmetic-shift-right. Such cases can be identified by matching a shift-left/shift-right pair but there are some issues with this in the context of combines. For example, suppose you can sign-extend 8-bit up to 32-bit with a target extend instruction. %1:_(s32) = G_SHL %0:_(s32), i32 24 # (I've inlined the G_CONSTANT for brevity) %2:_(s32) = G_ASHR %1:_(s32), i32 24 %3:_(s32) = G_ASHR %2:_(s32), i32 1 would reasonably combine to: %1:_(s32) = G_SHL %0:_(s32), i32 24 %2:_(s32) = G_ASHR %1:_(s32), i32 25 which no longer matches the special case. If your shifts and extend are equal cost, this would break even as a pair of shifts but if your shift is more expensive than the extend then it's cheaper as: %2:_(s32) = G_SEXT_INREG %0:_(s32), i32 8 %3:_(s32) = G_ASHR %2:_(s32), i32 1 It's possible to match the shift-pair in ISel and emit an extend and ashr. However, this is far from the only way to break this shift pair and make it hard to match the extends. Another example is that with the right known-zeros, this: %1:_(s32) = G_SHL %0:_(s32), i32 24 %2:_(s32) = G_ASHR %1:_(s32), i32 24 %3:_(s32) = G_MUL %2:_(s32), i32 2 can become: %1:_(s32) = G_SHL %0:_(s32), i32 24 %2:_(s32) = G_ASHR %1:_(s32), i32 23 All upstream targets have been configured to lower it to the current G_SHL,G_ASHR pair but will likely want to make it legal in some cases to handle their faster cases. To follow-up: Provide a way to legalize based on the constant. At the moment, I'm thinking that the best way to achieve this is to provide the MI in LegalityQuery but that opens the door to breaking core principles of the legalizer (legality is not context sensitive). That said, it's worth noting that looking at other instructions and acting on that information doesn't violate this principle in itself. It's only a violation if, at the end of legalization, a pass that checks legality without being able to see the context would say an instruction might not be legal. That's a fairly subtle distinction so to give a concrete example, saying %2 in: %1 = G_CONSTANT 16 %2 = G_SEXT_INREG %0, %1 is legal is in violation of that principle if the legality of %2 depends on %1 being constant and/or being 16. However, legalizing to either: %2 = G_SEXT_INREG %0, 16 or: %1 = G_CONSTANT 16 %2:_(s32) = G_SHL %0, %1 %3:_(s32) = G_ASHR %2, %1 depending on whether %1 is constant and 16 does not violate that principle since both outputs are genuinely legal. Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, arsenm Subscribers: sdardis, jvesely, wdng, nhaehnle, rovka, kristof.beyls, javed.absar, hiraditya, jrtc27, atanasyan, Petar.Avramovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61289 llvm-svn: 368487
* [SCEV] Return zero from computeConstantDifference(X, X)Nikolai Bozhenov2019-08-071-2/+68
| | | | | | | | | | | | Without this patch computeConstantDifference returns None for cases like these: computeConstantDifference(%x, %x) computeConstantDifference({%x,+,16}, {%x,+,16}) Differential Revision: https://reviews.llvm.org/D65474 llvm-svn: 368193
* DebugInfo/DWARF: Normalize DWARFObject members on the DWARF spec section namesDavid Blaikie2019-08-071-1/+1
| | | | | | | | | Some of these names were abbreviated, some were not, some pluralised, some not. Made the API difficult to use - since it's an exact 1:1 mapping to the DWARF sections - use those names (changing underscore separation for camel casing). llvm-svn: 368189
* Replace non-recursive sys::Mutex users with std::mutexBenjamin Kramer2019-08-071-2/+2
| | | | | | | Also remove a use of sys::MutexImpl, that's just evil. No functionality change intended. llvm-svn: 368157
* Remove support for 32-bit offsets in utility classes (5/5)Igor Kudrin2019-08-071-19/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D65641 llvm-svn: 368156
* [yaml2obj] Move core yaml2obj code into lib and include for use in unit testsAlex Brachet2019-08-072-0/+37
| | | | | | | | | | | | | | Reviewers: jhenderson, rupprecht, MaskRay, grimar, labath Reviewed By: rupprecht Subscribers: gribozavr, mgrang, seiya, mgorny, sbc100, hiraditya, aheejin, jakehehrlich, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65255 llvm-svn: 368119
* [GISel]: Add GISelKnownBits analysisAditya Nandakumar2019-08-066-2/+78
| | | | | | | | | | | | | | https://reviews.llvm.org/D65698 This adds a KnownBits analysis pass for GISel. This was done as a pass (compared to static functions) so that we can add other features such as caching queries(within a pass and across passes) in the future. This patch only adds the basic pass boiler plate, and implements a lazy non caching knownbits implementation (ported from SelectionDAG). I've also hooked up the AArch64PreLegalizerCombiner pass to use this - there should be no compile time regression as the analysis is lazy. llvm-svn: 368065
* [Path] Fix bug in make_absolute logicJonas Devlieghere2019-08-061-4/+13
| | | | | | | | | | | This fixes a bug for making path with a //net style root absolute. I discovered the bug while writing a test case for the VFS, which uses these paths because they're both legal absolute paths on Windows and Unix. Differential revision: https://reviews.llvm.org/D65675 llvm-svn: 368053
* Revert "[yaml2obj] Move core yaml2obj code into lib and include for use in ↵Dmitri Gribenko2019-08-062-37/+0
| | | | | | | | unit tests" This reverts commit r368021, it broke tests. llvm-svn: 368035
* [AArch64] NFC: Add generic StackOffset to describe scalable offsets.Sander de Smalen2019-08-062-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support spilling/filling of scalable vectors we need a more generic representation of a stack offset than simply 'int'. For this we introduce the StackOffset struct, which comprises multiple offsets sized by their respective MVTs. Byte-offsets will thus be a simple tuple such as { offset, MVT::i8 }. Adding two byte-offsets will result in a byte offset { offsetA + offsetB, MVT::i8 }. When two offsets have different types, we can canonicalise them to use the same MVT, as long as their runtime sizes are guaranteed to have the same size-ratio as they would have at compile-time. When we have both scalable- and fixed-size objects on the stack, we can create an offset that is: ({ offset_fixed, MVT::i8 } + { offset_scalable, MVT::nxv1i8 }) The struct also contains a getForFrameOffset() method that is specific to AArch64 and decomposes the frame-offset to be used directly in instructions that operate on the stack or index into the stack. Note: This patch adds StackOffset as an AArch64-only concept, but we would like to make this a generic concept/struct that is supported by all interfaces that take or return stack offsets (currently as 'int'). Since that would be a bigger change that is currently pending on D32530 landing, we thought it makes sense to first show/prove the concept in the AArch64 target before proposing to roll this out further. Reviewers: thegameg, rovka, t.p.northover, efriedma, greened Reviewed By: rovka, greened Differential Revision: https://reviews.llvm.org/D61435 llvm-svn: 368024
OpenPOWER on IntegriCloud