summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
* GlobalISel: Try to make legalize rules more useful for vectorsMatt Arsenault2019-02-072-0/+181
| | | | | | | Mostly keep the existing functions on scalars, but add versions which also operate based on the vector element size. llvm-svn: 353430
* Move DomTreeUpdater from IR to AnalysisRichard Trieu2019-02-065-6/+6
| | | | | | | | DomTreeUpdater depends on headers from Analysis, but is in IR. This is a layering violation since Analysis depends on IR. Relocate this code from IR to Analysis to fix the layering violation. llvm-svn: 353265
* [ADT] Add a fallible_iterator wrapper.Lang Hames2019-02-052-0/+294
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A fallible iterator is one whose increment or decrement operations may fail. This would usually be supported by replacing the ++ and -- operators with methods that return error: class MyFallibleIterator { public: // ... Error inc(); Errro dec(); // ... }; The downside of this style is that it no longer conforms to the C++ iterator concept, and can not make use of standard algorithms and features such as range-based for loops. The fallible_iterator wrapper takes an iterator written in the style above and adapts it to (mostly) conform with the C++ iterator concept. It does this by providing standard ++ and -- operator implementations, returning any errors generated via a side channel (an Error reference passed into the wrapper at construction time), and immediately jumping the iterator to a known 'end' value upon error. It also marks the Error as checked any time an iterator is compared with a known end value and found to be inequal, allowing early exit from loops without redundant error checking*. Usage looks like: MyFallibleIterator I = ..., E = ...; Error Err = Error::success(); for (auto &Elem : make_fallible_range(I, E, Err)) { // Loop body is only entered when safe. // Early exits from loop body permitted without checking Err. if (SomeCondition) return; } if (Err) // Handle error. * Since failure causes a fallible iterator to jump to end, testing that a fallible iterator is not an end value implicitly verifies that the error is a success value, and so is equivalent to an error check. Reviewers: dblaikie, rupprecht Subscribers: mgorny, dexonsmith, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57618 llvm-svn: 353237
* Recommit: Add support for prefix-only CLI optionsThomas Preud'homme2019-02-051-0/+74
| | | | | | | | | | | | | | | | | | | | | | Summary: Add support for options that always prefix their value, giving an error if the value is in the next argument or if the option is given a value assignment (ie. opt=val). This is the desired behavior for the -D option of FileCheck for instance. Copyright: - Linaro (changes in version 2 of revision D55940) - GraphCore (changes in later versions and introduced when creating D56549) Reviewers: jdenny Subscribers: llvm-commits, probinson, kristina, hiraditya, JonChesterfield Differential Revision: https://reviews.llvm.org/D56549 llvm-svn: 353172
* GlobalISel: Fix not calling observer when legalizing bitcount opsMatt Arsenault2019-02-041-0/+65
| | | | | | This was hiding bugs from never legalizing the source type. llvm-svn: 353102
* GlobalISel: Fix CheckMachineFunction passing if ReadCheckFile filesMatt Arsenault2019-02-041-1/+3
| | | | | | | This could be tested, but the FileCheck library spams the error message to the console. llvm-svn: 353081
* GlobalISel: Allow constructing SrcOp/DstOp from MachineOperandMatt Arsenault2019-02-041-0/+25
| | | | llvm-svn: 353080
* GlobalISel: Fix CSE handling of buildConstantMatt Arsenault2019-02-042-4/+49
| | | | | | | | | | | | | | | | This fixes two problems with CSE done in buildConstant. First, this would hit an assert when used with a vector result type. Solve this by allowing CSE on the vector elements, but not on the result vector for now. Second, this was also performing the CSE based on the input ConstantInt pointer. The underlying buildConstant could potentially convert the constant depending on the result type, giving in a different ConstantInt*. Stop allowing the APInt and ConstantInt forms from automatically casting to the result type to avoid any similar problems in the future. llvm-svn: 353077
* GlobalISel: Improve gtest usageMatt Arsenault2019-02-049-169/+188
| | | | | | | Don't unnecessarily use ASSERT_*, and print the MachineFunction on failure. llvm-svn: 353072
* GlobalISel: Fix moreElementsToNextPow2Matt Arsenault2019-02-041-0/+40
| | | | | | | | | This was completely broken. The condition was inverted, and changed the element type for vectors of pointers. Fixes bug 40592. llvm-svn: 353069
* [CommandLine] Don't print empty sentinel values from EnumValN lists in help textJames Henderson2019-02-041-0/+215
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make an option value truly optional, both the ValueOptional attribute and an empty-named value are required. Prior to this change, this empty-named value appears in the command-line help text: -some-option - some help text =v1 - description 1 =v2 - description 2 = - This change improves the help text for these sort of options in a number of ways: 1) ValueOptional options with an empty-named value now print their help text twice: both without and then with '=<value>' after the name. The latter version then lists the allowed values after it. 2) Empty-named values with no help text in ValueOptional options are not listed in the permitted values. -some-option - some help text -some-option=<value> - some help text =v1 - description 1 =v2 - description 2 3) Otherwise empty-named options are printed as =<empty> rather than simply '='. 4) Option values without help text do not have the '-' separator printed. -some-option=<value> - some help text =v1 - description 1 =v2 =<empty> - description It also tweaks the llvm-symbolizer -functions help text to not print a trailing ':' as that looks bad combined with 1) above. This is mostly a reland of r353048 which in turn was a reland of r352750. Reviewed by: ruiu, thopre, mstorsjo Differential Revision: https://reviews.llvm.org/D57030 llvm-svn: 353053
* Revert r353048.James Henderson2019-02-041-215/+0
| | | | | | It was causing unexpected unit test failures on build bots. llvm-svn: 353050
* [CommandLine] Don't print empty sentinel values from EnumValN lists in help textJames Henderson2019-02-041-0/+215
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make an option value truly optional, both the ValueOptional attribute and an empty-named value are required. Prior to this change, this empty-named value appears in the command-line help text: -some-option - some help text =v1 - description 1 =v2 - description 2 = - This change improves the help text for these sort of options in a number of ways: 1) ValueOptional options with an empty-named value now print their help text twice: both without and then with '=<value>' after the name. The latter version then lists the allowed values after it. 2) Empty-named values with no help text in ValueOptional options are not listed in the permitted values. -some-option - some help text -some-option=<value> - some help text =v1 - description 1 =v2 - description 2 3) Otherwise empty-named options are printed as =<empty> rather than simply '='. 4) Option values without help text do not have the '-' separator printed. -some-option=<value> - some help text =v1 - description 1 =v2 =<empty> - description It also tweaks the llvm-symbolizer -functions help text to not print a trailing ':' as that looks bad combined with 1) above. This is mostly a reland of r352750. Reviewed by: ruiu, thopre, mstorsjo Differential Revision: https://reviews.llvm.org/D57030 llvm-svn: 353048
* [opaque pointer types] Pass value type to GetElementPtr creation.James Y Knight2019-02-014-4/+6
| | | | | | | | | This cleans up all GetElementPtr creation in LLVM to explicitly pass a value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57173 llvm-svn: 352913
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-0113-57/+62
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* [opaque pointer types] Pass function types to InvokeInst creation.James Y Knight2019-02-011-3/+4
| | | | | | | | | This cleans up all InvokeInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57171 llvm-svn: 352910
* [opaque pointer types] Pass function types to CallInst creation.James Y Knight2019-02-013-9/+9
| | | | | | | | | This cleans up all CallInst creation in LLVM to explicitly pass a function type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57170 llvm-svn: 352909
* Revert r352750.James Henderson2019-02-011-134/+0
| | | | | | | This was causing a build bot failure: http://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/15346/ llvm-svn: 352848
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-0110-36/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-3110-41/+36
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-3110-36/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* [CommandLine] Improve help text for cl::values style optionsJames Henderson2019-01-311-0/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make an option value truly optional, both the ValueOptional and an empty-named value are required. This empty-named value appears in the command-line help text, which is not ideal. This change improves the help text for these sort of options in a number of ways: 1) ValueOptional options with an empty-named value now print their help text twice: both without and then with '=<value>' after the name. The latter version then lists the allowed values after it. 2) Empty-named values with no help text in ValueOptional options are not listed in the permitted values. 3) Otherwise empty-named options are printed as =<empty> rather than simply '='. 4) Option values without help text do not have the '-' separator printed. It also tweaks the llvm-symbolizer -functions help text to not print a trailing ':' as that looks bad combined with 1) above. Reviewed by: thopre, ruiu Differential Revision: https://reviews.llvm.org/D57030 llvm-svn: 352750
* GlobalISel: Allow bitcount ops to have different result typeMatt Arsenault2019-01-311-33/+47
| | | | | | For AMDGPU the result is always 32-bit for 64-bit inputs. llvm-svn: 352717
* [WebAssembly] Exception handling: Switch to the new proposalHeejin Ahn2019-01-301-142/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This switches the EH implementation to the new proposal: https://github.com/WebAssembly/exception-handling/blob/master/proposals/Exceptions.md (The previous proposal was https://github.com/WebAssembly/exception-handling/blob/master/proposals/old/Exceptions.md) - Instruction changes - Now we have one single `catch` instruction that returns a except_ref value - `throw` now can take variable number of operations - `rethrow` does not have 'depth' argument anymore - `br_on_exn` queries an except_ref to see if it matches the tag and branches to the given label if true. - `extract_exception` is a pseudo instruction that simulates popping values from wasm stack. This is to make `br_on_exn`, a very special instruction, work: `br_on_exn` puts values onto the stack only if it is taken, and the # of values can vay depending on the tag. - Now there's only one `catch` per `try`, this patch removes all special handling for terminate pad with a call to `__clang_call_terminate`. Before it was the only case there are two catch clauses (a normal `catch` and `catch_all` per `try`). - Make `rethrow` act as a terminator like `throw`. This splits BB after `rethrow` in WasmEHPrepare, and deletes an unnecessary `unreachable` after `rethrow` in LateEHPrepare. - Now we stop at all catchpads (because we add wasm `catch` instruction that catches all exceptions), this creates new `findWasmUnwindDestinations` function in SelectionDAGBuilder. - Now we use `br_on_exn` instrution to figure out if an except_ref matches the current tag or not, LateEHPrepare generates this sequence for catch pads: ``` catch block i32 br_on_exn $__cpp_exception end_block extract_exception ``` - Branch analysis for `br_on_exn` in WebAssemblyInstrInfo - Other various misc. changes to switch to the new proposal. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D57134 llvm-svn: 352598
* [VFS] Fix warning and use better check.Michael J. Spencer2019-01-291-1/+1
| | | | llvm-svn: 352527
* VERSION_GREATER_EQUAL not supported in llvm cmake.Ranjeet Singh2019-01-281-1/+1
| | | | | | | | | | | | Patch https://reviews.llvm.org/D56329 caused build failures for me when building on Windows because of the use of cmake operator 'VERSION_GREATER_EQUAL' which isn't supported in older versions of cmake. The llvm website states that minimum required version of cmake for building llvm is 3.4.3 https://llvm.org/docs/CMake.html Differential Revision: https://reviews.llvm.org/D57326 llvm-svn: 352378
* Fix some warnings on MSVCAlexandre Ganea2019-01-271-1/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D56329 llvm-svn: 352322
* Revert "Add support for prefix-only CLI options"Thomas Preud'homme2019-01-271-75/+1
| | | | | | This reverts commit r351038. llvm-svn: 352310
* GlobalISel: Fix address space limit in LLTMatt Arsenault2019-01-261-26/+33
| | | | | | | | | | | | The IR enforced limit for the address space is 24-bits, but LLT was only using 23-bits. Additionally, the argument to the constructor was truncating to 16-bits. A similar problem still exists for the number of vector elements. The IR enforces no limit, so if you try to use a vector with > 65535 elements the IRTranslator asserts in the LLT constructor. llvm-svn: 352264
* Revert r351954 "Add a value_type to ArrayRef."Clement Courbet2019-01-251-8/+0
| | | | | | This breaks arm self-hosted buildbots. llvm-svn: 352206
* GlobalISel: Add helper to LLT to get a scalar or vectorMatt Arsenault2019-01-251-0/+15
| | | | llvm-svn: 352136
* [llvm] Clarify responsiblity of some of DILocation discriminator APIsMircea Trofin2019-01-241-11/+17
| | | | | | | | | | | | | | | | | | | | | Summary: Renamed setBaseDiscriminator to cloneWithBaseDiscriminator, to match similar APIs. Also changed its behavior to copy over the other discriminator components, instead of eliding them. Renamed cloneWithDuplicationFactor to cloneByMultiplyingDuplicationFactor, which more closely matches what this API does. Reviewers: dblaikie, wmi Reviewed By: dblaikie Subscribers: zzheng, llvm-commits Differential Revision: https://reviews.llvm.org/D56220 llvm-svn: 351996
* [ADT] Notify ilist traits about in-list transfersReid Kleckner2019-01-231-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously no client of ilist traits has needed to know about transfers of nodes within the same list, so as an optimization, ilist doesn't call transferNodesFromList in that case. However, now there are clients that want to use ilist traits to cache instruction ordering information to optimize dominance queries of instructions in the same basic block. This change updates the existing ilist traits users to detect in-list transfers and do nothing in that case. After this change, we can start caching instruction ordering information in LLVM IR data structures. There are two main ways to do that: - by putting an order integer into the Instruction class - by maintaining order integers in a hash table on BasicBlock I plan to implement and measure both, but I wanted to commit this change first to enable other out of tree ilist clients to implement this optimization as well. Reviewers: lattner, hfinkel, chandlerc Subscribers: hiraditya, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D57120 llvm-svn: 351992
* [LV][VPlan] Change to implement VPlan based predication forHideki Saito2019-01-232-0/+231
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VPlan-native path Context: Patch Series #2 for outer loop vectorization support in LV using VPlan. (RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-December/119523.html). Patch series #2 checks that inner loops are still trivially lock-step among all vector elements. Non-loop branches are blindly assumed as divergent. Changes here implement VPlan based predication algorithm to compute predicates for blocks that need predication. Predicates are computed for the VPLoop region in reverse post order. A block's predicate is computed as OR of the masks of all incoming edges. The mask for an incoming edge is computed as AND of predecessor block's predicate and either predecessor's Condition bit or NOT(Condition bit) depending on whether the edge from predecessor block to the current block is true or false edge. Reviewers: fhahn, rengolin, hsaito, dcaballe Reviewed By: fhahn Patch by Satish Guggilla, thanks! Differential Revision: https://reviews.llvm.org/D53349 llvm-svn: 351990
* Re-land rL322538 "Add a value_type to ArrayRef."Clement Courbet2019-01-231-0/+8
| | | | llvm-svn: 351954
* GlobalISel: Make buildConstant handle vectorsMatt Arsenault2019-01-223-7/+43
| | | | | | | Produce a splat build_vector similar to how SelectionDAG::getConstant does. llvm-svn: 351880
* Fix compilation error with gcc 4.8Pavel Labath2019-01-211-4/+4
| | | | | | | This version of gcc seems to be having issues with raw literals inside macro arguments. I change the string to use regular string literals instead. llvm-svn: 351756
* [NFC] Fix warnings in unit test of r351725Max Kazantsev2019-01-211-6/+6
| | | | llvm-svn: 351726
* [SCEV][NFC] Introduces expression sizes estimationMax Kazantsev2019-01-211-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces the field `ExpressionSize` in SCEV. This field is calculated only once on SCEV creation, and it represents the complexity of this SCEV from arithmetical point of view (not from the point of the number of actual different SCEV nodes that are used in the expression). Roughly saying, it is the number of operands and operations symbols when we print this SCEV. A formal definition is following: if SCEV `X` has operands `Op1`, `Op2`, ..., `OpN`, then Size(X) = 1 + Size(Op1) + Size(Op2) + ... + Size(OpN). Size of SCEVConstant and SCEVUnknown is one. Expression size may be used as a universal way to limit SCEV transformations for huge SCEVs. Currently, we have a bunch of options that represents various limits (such as recursion depth limit) that may not make any sense from the point of view of a LLVM users who is not familiar with SCEV internals, and all these different options pursue one goal. A more general rule that may potentially allow us to get rid of this redundancy in options is "do not make transformations with SCEVs of huge size". It can apply to all SCEV traversals and transformations that may need to visit a SCEV node more than once, hence they are prone to combinatorial explosions. This patch only introduces SCEV sizes calculation as NFC, its utilization will be introduced in follow-up patches. Differential Revision: https://reviews.llvm.org/D35989 Reviewed By: reames llvm-svn: 351725
* Add missing test fileSerge Guelton2019-01-201-0/+26
| | | | llvm-svn: 351702
* Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>Serge Guelton2019-01-2010-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-193-12/+9
| | | | | | | | | | | | | | | | | | to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-19332-1328/+996
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Remove F_modify flag from FileOutputBuffer.Rui Ueyama2019-01-191-49/+0
| | | | | | | | This code is dead. There is no use of the feature in the entire LLVM codebase. Differential Revision: https://reviews.llvm.org/D56939 llvm-svn: 351613
* Add __[_[_]]Z demangling to new common demangle functionJames Henderson2019-01-181-0/+6
| | | | | | | | | | | | This is a follow-up to r351448. It adds support for other _*Z extensions of the Itanium demanling, to the newly available demangle function heuristic. Reviewed by: erik.pilkington, rupprecht, grimar Differential Revision: https://reviews.llvm.org/D56855 llvm-svn: 351551
* [ADT] Add streaming operators for llvm::OptionalPavel Labath2019-01-181-1/+51
| | | | | | | | | | | | | | | | | | | | | | | Summary: The operators simply print the underlying value or "None". The trickier part of this patch is making sure the streaming operators work even in unit tests (which was my primary motivation, though I can also see them being useful elsewhere). Since the stream operator was a template, implicit conversions did not kick in, and our gtest glue code was explicitly introducing an implicit conversion to make sure other implicit conversions do not kick in :P. I resolve that by specializing llvm_gtest::StreamSwitch for llvm:Optional<T>. Reviewers: sammccall, dblaikie Reviewed By: sammccall Subscribers: mgorny, dexonsmith, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D56795 llvm-svn: 351548
* Move demangling function from llvm-objdump to Demangle libraryJames Henderson2019-01-172-0/+20
| | | | | | | | | | | | | | | | This allows it to be used in an upcoming llvm-readobj change. A small change in internal behaviour of the function is to always call the microsoftDemangle function if the string does not have an itanium encoding prefix, rather than only if it starts with '?'. This is harmless because the microsoftDemangle function does the same check already. Reviewed by: grimar, erik.pilkington Differential Revision: https://reviews.llvm.org/D56721 llvm-svn: 351448
* [Support] Remove error return value from one overload of fs::make_absolutePavel Labath2019-01-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: The version of make_absolute which accepted a specific directory to use as the "base" for the computation could never fail, even though it returned a std::error_code. The reason for that seems to be historical -- the CWD flavour (which can fail due to failure to retrieve CWD) was there first, and the new version was implemented by extending that. This removes the error return value from the non-CWD overload and reimplements the CWD version on top of that. This enables us to remove some dead code where people were pessimistically trying to handle the errors returned from this function. Reviewers: zturner, sammccall Subscribers: hiraditya, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D56599 llvm-svn: 351317
* [WebAssembly] COWS has been renamed to WASI.Dan Gohman2019-01-161-8/+8
| | | | llvm-svn: 351297
* [GISel]: Add support for CSEing continuously during GISel passes.Aditya Nandakumar2019-01-164-49/+142
| | | | | | | | | | https://reviews.llvm.org/D52803 This patch adds support to continuously CSE instructions during each of the GISel passes. It consists of a GISelCSEInfo analysis pass that can be used by the CSEMIRBuilder. llvm-svn: 351283
OpenPOWER on IntegriCloud