summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [WebAssembly] SIMD SplatsDerek Schuff2018-08-151-0/+28
| | | | | | | | | | Implement and test SIMD splat ops. Patch by Thomas Lively Differential Revision: https://reviews.llvm.org/D50741 llvm-svn: 339744
* [SDAG] Remove the reliance on MI's allocation strategy forChandler Carruth2018-08-1421-202/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `MachineMemOperand` pointers attached to `MachineSDNodes` and instead have the `SelectionDAG` fully manage the memory for this array. Prior to this change, the memory management was deeply confusing here -- The way the MI was built relied on the `SelectionDAG` allocating memory for these arrays of pointers using the `MachineFunction`'s allocator so that the raw pointer to the array could be blindly copied into an eventual `MachineInstr`. This creates a hard coupling between how `MachineInstr`s allocate their array of `MachineMemOperand` pointers and how the `MachineSDNode` does. This change is motivated in large part by a change I am making to how `MachineFunction` allocates these pointers, but it seems like a layering improvement as well. This would run the risk of increasing allocations overall, but I've implemented an optimization that should avoid that by storing a single `MachineMemOperand` pointer directly instead of allocating anything. This is expected to be a net win because the vast majority of uses of these only need a single pointer. As a side-effect, this makes the API for updating a `MachineSDNode` and a `MachineInstr` reasonably different which seems nice to avoid unexpected coupling of these two layers. We can map between them, but we shouldn't be *surprised* at where that occurs. =] Differential Revision: https://reviews.llvm.org/D50680 llvm-svn: 339740
* [FPEnv] Scalarize StrictFP vector operationsCameron McInally2018-08-142-0/+50
| | | | | | | | Add a helper function to scalarize constrained FP operations as needed. Differential Revision: https://reviews.llvm.org/D50720 llvm-svn: 339735
* [ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly.Eli Friedman2018-08-145-7/+31
| | | | | | | | | | | | | | | | | | | | | Intentionally excluding nodes from the DAGCombine worklist is likely to lead to weird optimizations and infinite loops, so it's generally a bad idea. To avoid the infinite loops, fix DAGCombine to use the isDesirableToCommuteWithShift target hook before performing the transforms in question, and implement the target hook in the ARM backend disable the transforms in question. Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a reduced testcase for that bug. But we should have sufficient test coverage for PerformSHLSimplify given that we're not playing weird tricks with the worklist. I can try to bugpoint it if necessary, though.) Differential Revision: https://reviews.llvm.org/D50667 llvm-svn: 339734
* [SanitizerCoverage] Add associated metadata to PC guards.Matt Morehouse2018-08-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: Without this metadata LLD strips unused PC table entries but won't strip unused guards. This metadata also seems to influence the linker to change the ordering in the PC guard section to match that of the PC table section. The libFuzzer runtime library depends on the ordering of the PC table and PC guard sections being the same. This is not generally guaranteed, so we may need to redesign PC tables/guards/counters in the future. Reviewers: eugenis Reviewed By: eugenis Subscribers: kcc, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50483 llvm-svn: 339733
* NFC: Clarify comment in loop vectorization legalityAnna Thomas2018-08-141-1/+2
| | | | | | | Clarifying the comment about PSCEV and external IV users by referencing the bug in question. llvm-svn: 339722
* [DebugInfoMetadata] Added DIFlags interface in DIBasicType.Adrian Prantl2018-08-149-15/+33
| | | | | | | | | | | Flags in DIBasicType will be used to pass attributes used in DW_TAG_base_type, such as DW_AT_endianity. Patch by Chirag Patel! Differential Revision: https://reviews.llvm.org/D49610 llvm-svn: 339714
* [WebAssembly] Fix encoding of non-SIMD vector-typed instructionsHeejin Ahn2018-08-142-29/+32
| | | | | | | | | | | | | | | | | | | Previously SIMD_I was the same as a normal instruction except for the addition of a HasSIM128 predicate. However, rL339186 changed the encoding of SIMD_I instructions to automatically contain the SIMD prefix byte. This broke the encoding of non-SIMD vector-typed instructions, which had instantiated SIMD_I. This CL corrects this error. Reviewers: aheejin Subscribers: sunfish, jgravelle-google, sbc100, llvm-commits Differential Revision: https://reviews.llvm.org/D50682 Patch by Thomas Lively (tlively) llvm-svn: 339710
* [MS Demangler] Fix some minor formatting bugs.Zachary Turner2018-08-141-7/+5
| | | | | | | | | | | | | | | | 1) We print __restrict twice on member pointers. This is fixed and relevant tests are re-enabled. 2) Several tests were disabled because of printing slightly different output than undname. These were confirmed to be bugs in undname, so we just re-enable the tests. 3) The test for printing reference temporaries is re-enabled. This is a clang mangling extension, so we have some flexibility with how we demangle it. The output currently looks fine, so we just re-enable the test with no fixes. llvm-svn: 339708
* [WebAssembly] SIMD extract_laneHeejin Ahn2018-08-141-2/+62
| | | | | | | | | | | | | | | | | Implement instruction selection for all versions of the extract_lane instruction. Use explicit sext/zext to differentiate between extract_lane_s and extract_lane_u for applicable types, otherwise default to extract_lane_u. Reviewers: aheejin Subscribers: sunfish, jgravelle-google, sbc100, llvm-commits Differential Revision: https://reviews.llvm.org/D50597 Patch by Thomas Lively (tlively) llvm-svn: 339707
* [Tablegen][MCInstPredicate] Removed redundant template argument from class ↵Andrea Di Biagio2018-08-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | TIIPredicate, and implemented verification rules for TIIPredicates. This patch removes redundant template argument `TargetName` from TIIPredicate. Tablegen can always infer the target name from the context. So we don't need to force users of TIIPredicate to always specify it. This allows us to better modularize the tablegen class hierarchy for the so-called "function predicates". class FunctionPredicateBase has been added; it is currently used as a building block for TIIPredicates. However, I plan to reuse that class to model other function predicate classes too (i.e. not just TIIPredicates). For example, this can be a first step towards implementing proper support for dependency breaking instructions in tablegen. This patch also adds a verification step on TIIPredicates in tablegen. We cannot have multiple TIIPredicates with the same name. Otherwise, this will cause build errors later on, when tablegen'd .inc files are included by cpp files and then compiled. Differential Revision: https://reviews.llvm.org/D50708 llvm-svn: 339706
* [LV] Teach about non header phis that have uses outside the loopAnna Thomas2018-08-142-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch teaches the loop vectorizer to vectorize loops with non header phis that have have outside uses. This is because the iteration dependence distance for these phis can be widened upto VF (similar to how we do for induction/reduction) if they do not have a cyclic dependence with header phis. When identifying reduction/induction/first order recurrence header phis, we already identify if there are any cyclic dependencies that prevents vectorization. The vectorizer is taught to extract the last element from the vectorized phi and update the scalar loop exit block phi to contain this extracted element from the vector loop. This patch can be extended to vectorize loops where instructions other than phis have outside uses. Reviewers: Ayal, mkuper, mssimpso, efriedma Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50579 llvm-svn: 339703
* Revert "[DebugInfo] Generate DWARF debug information for labels. (Fix leak ↵Bruno Cardoso Lopes2018-08-1416-407/+149
| | | | | | | | | | | | problems)" This reverts commit cb8c5e417d55141f3f079a8a876e786f44308336 / r339676. This causing a test to fail in http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/48406/ LLVM :: DebugInfo/Generic/debug-label.ll llvm-svn: 339700
* [X86][SSE] Avoid duplicate shuffle input sources in ↵Simon Pilgrim2018-08-141-16/+19
| | | | | | | | | | combineX86ShufflesRecursively rL339686 added the case where a faux shuffle might have repeated shuffle inputs coming from either side of the OR(). This patch improves the insertion of the inputs into the source ops lists to account for this, as well as making it trivial to add support for shuffles with more than 2 inputs in the future. llvm-svn: 339696
* [DomTree] Cleanup Update and LegalizeUpdate API moved to Support header.Alina Sbirlea2018-08-141-1/+1
| | | | | | | | | | | | | | Summary: Clean-up following D50479. Make Update and LegalizeUpdate refer to the utilities in Support/CFGUpdate. Reviewers: kuhar Subscribers: sanjoy, jlebar, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D50669 llvm-svn: 339694
* [DAG] Avoid redundant chain transversal in store merge cycle check. NFCI.Nirav Dave2018-08-141-1/+2
| | | | | | Patch by Henric Karlsson. llvm-svn: 339688
* [X86][SSE] Add shuffle combine support for OR(PSHUFB,PSHUFB) style patterns.Simon Pilgrim2018-08-141-0/+53
| | | | | | If each element is zero from one (or both) inputs then we can combine these into a single shuffle mask. llvm-svn: 339686
* [Inliner] add inliner stats to new pm version of inlinerFedor Sergeev2018-08-141-0/+3
| | | | | | Increment existing NumInlined and NumDeleted stats in InlinerPass::run. llvm-svn: 339682
* [X86][SSE] Generalize lowerVectorShuffleAsBlendOfPSHUFBs to work with any ↵Simon Pilgrim2018-08-141-30/+31
| | | | | | | | vXi8 type. We still only use this for v16i8, but this cleans up the code to support v32i8/v64i8 sometime in the future. llvm-svn: 339679
* [DebugInfo] Generate DWARF debug information for labels. (Fix leak problems)Hsiangkai Wang2018-08-1416-149/+407
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two forms for label debug information in DWARF format. 1. Labels in a non-inlined function: DW_TAG_label DW_AT_name DW_AT_decl_file DW_AT_decl_line DW_AT_low_pc 2. Labels in an inlined function: DW_TAG_label DW_AT_abstract_origin DW_AT_low_pc We will collect label information from DBG_LABEL. Before every DBG_LABEL, we will generate a temporary symbol to denote the location of the label. The symbol could be used to get DW_AT_low_pc afterwards. So, we create a mapping between 'inlined label' and DBG_LABEL MachineInstr in DebugHandlerBase. The DBG_LABEL in the mapping is used to query the symbol before it. The AbstractLabels in DwarfCompileUnit is used to process labels in inlined functions. We also keep a mapping between scope and labels in DwarfFile to help to generate correct tree structure of DIEs. It also generates label debug information under global isel. Differential Revision: https://reviews.llvm.org/D45556 llvm-svn: 339676
* [GlobalISel][IRTranslator] Fix a bug in handling repeating struct types ↵Amara Emerson2018-08-141-0/+2
| | | | | | | | during argument lowering. Differential Revision: https://reviews.llvm.org/D49442 llvm-svn: 339674
* Fix MSVC "compiler limit: blocks nested too deeply" error. NFCI.Simon Pilgrim2018-08-141-35/+19
| | | | | | MSVC only accepts if-else chains up to 127 blocks long. I've had to merge a number of intrinsic cases together to get back below this limit, resulting in some duplication of string matches; this shouldn't cause any notable increase in runtime (and even then only for old IR, nothing that clang currently emits). llvm-svn: 339666
* [X86] Constant folding of adds/subs intrinsicsTomasz Krupa2018-08-141-0/+98
| | | | | | | | | | | | | | Summary: This adds constant folding of signed add/sub with saturation intrinsics. Reviewers: craig.topper, spatel, RKSimon, chandlerc, efriedma Reviewed By: craig.topper Subscribers: rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D50499 llvm-svn: 339659
* [RISCV] Fix incorrect use of MCInstBuilderRoger Ferrer Ibanez2018-08-141-8/+6
| | | | | | | | | | | | | | | | | | This is a fix for r339314. MCInstBuilder uses the named parameter idiom and an 'operator MCInst&' to ease the creation of MCInsts. As the object of MCInstBuilder owns the MCInst is manipulating, the lifetime of the MCInst is bound to that of MCInstBuilder. In r339314 I bound a reference to the MCInst in an initializer. The temporary of MCInstBuilder (and also its MCInst) is destroyed at the end of the declaration leading to a dangling reference. Fix this by using MCInstBuilder inside an argument of a function call. Temporaries in function calls are destroyed in the enclosing full expression, so the the reference to MCInst is still valid when emitToStreamer executes. llvm-svn: 339654
* Test commit: fix punctuationChih-Mao Chen2018-08-141-1/+1
| | | | llvm-svn: 339652
* [X86] Lowering addus/subus intrinsics to native IRTomasz Krupa2018-08-143-22/+207
| | | | | | | | | | | | | | | | | | | Summary: This revision improves previous version (rL330322) which has been reverted due to crashes. This is the patch that lowers x86 intrinsics to native IR in order to enable optimizations. The patch also includes folding of previously missing saturation patterns so that IR emits the same machine instructions as the intrinsics. Reviewers: craig.topper, spatel, RKSimon Reviewed By: craig.topper Subscribers: mike.dvoretsky, DavidKreitzer, sroland, llvm-commits Differential Revision: https://reviews.llvm.org/D46179 llvm-svn: 339650
* [ARM] ParallelDSP: add option to enable/disable the passSjoerd Meijer2018-08-141-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D50511 llvm-svn: 339645
* [ThinLTO] Fix printing of WPD remarksTeresa Johnson2018-08-141-2/+4
| | | | | | | | | | | | | | | | | Summary: When WPD is performed in a ThinLTO backend, the function may be created if it isn't already in that module. Module::getOrInsertFunction may add a bitcast, in which case the returned Constant is not a Function and doesn't have a name. Invoke stripPointerCasts() on the returned value where we access its name. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D49959 llvm-svn: 339640
* [ThinLTO] Handle optional args in assembly format for ConstVCallsTeresa Johnson2018-08-142-4/+12
| | | | | | | | | | | | | | | | Summary: The AsmWriter was only writing the Args for a ConstVCall if it was non-empty, however, the LLParser was always expecting it. To aid in making it optional, surround the ConstVCall VFuncId and Args in parentheses when writing, then make the Args optional when reading. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D49960 llvm-svn: 339637
* [BasicAA] Don't assume tail calls with byval don't alias allocasReid Kleckner2018-08-141-6/+7
| | | | | | | | | | | | | | | | | | | | Summary: Calls marked 'tail' cannot read or write allocas from the current frame because the current frame might be destroyed by the time they run. However, a tail call may use an alloca with byval. Calling with byval copies the contents of the alloca into argument registers or stack slots, so there is no lifetime issue. Tail calls never modify allocas, so we can return just ModRefInfo::Ref. Fixes PR38466, a longstanding bug. Reviewers: hfinkel, nlewycky, gbiv, george.burgess.iv Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50679 llvm-svn: 339636
* Revert "[WebAssembly] Added default stack-only instruction mode for MC."Wouter van Oortmerssen2018-08-136-487/+256
| | | | | | This reverts commit 917a99b71ce21c975be7bfbf66f4040f965d9f3c. llvm-svn: 339630
* [Support] NFC: Allow modifying access/modification times independently in ↵Jordan Rupprecht2018-08-132-7/+14
| | | | | | | | | | | | | | | | | sys::fs::setLastModificationAndAccessTime. Summary: Add an overload to sys::fs::setLastModificationAndAccessTime that allows setting last access and modification times separately. This will allow tools to use this API when they want to preserve both the access and modification times from an input file, which may be different. Also note that both the POSIX (futimens/futimes) and Windows (SetFileTime) APIs take the two timestamps in the order of (1) access (2) modification time, so this renames the method to "setLastAccessAndModificationTime" to make it clear which timestamp is which. For existing callers, the 1-arg overload just sets both timestamps to the same thing. Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50521 llvm-svn: 339628
* [AST] Minor formatting cleanup [NFC]Philip Reames2018-08-131-8/+4
| | | | llvm-svn: 339627
* [AST] Cleanup code by using MemoryLocation utility [NFC]Philip Reames2018-08-131-43/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D50588 llvm-svn: 339625
* [X86] Don't ignore 0x66 prefix on relative jumps in 64-bit mode. Fix opcode ↵Craig Topper2018-08-131-39/+12
| | | | | | | | | | | | | | | | selection of relative jumps in 16-bit mode. Treat jno/jo like other jcc instructions. The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same. While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day. The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with. While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them. Fixes PR38537. llvm-svn: 339622
* [InstCombine] Re-land: Optimize redundant 'signed truncation check pattern'.Roman Lebedev2018-08-131-0/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This comes with `Implicit Conversion Sanitizer - integer sign change` (D50250): ``` signed char test(unsigned int x) { return x; } ``` `clang++ -fsanitize=implicit-conversion -S -emit-llvm -o - /tmp/test.cpp -O3` * Old: {F6904292} * With this patch: {F6904294} General pattern: X & Y Where `Y` is checking that all the high bits (covered by a mask `4294967168`) are uniform, i.e. `%arg & 4294967168` can be either `4294967168` or `0` Pattern can be one of: %t = add i32 %arg, 128 %r = icmp ult i32 %t, 256 Or %t0 = shl i32 %arg, 24 %t1 = ashr i32 %t0, 24 %r = icmp eq i32 %t1, %arg Or %t0 = trunc i32 %arg to i8 %t1 = sext i8 %t0 to i32 %r = icmp eq i32 %t1, %arg This pattern is a signed truncation check. And `X` is checking that some bit in that same mask is zero. I.e. can be one of: %r = icmp sgt i32 %arg, -1 Or %t = and i32 %arg, 2147483648 %r = icmp eq i32 %t, 0 Since we are checking that all the bits in that mask are the same, and a particular bit is zero, what we are really checking is that all the masked bits are zero. So this should be transformed to: %r = icmp ult i32 %arg, 128 The transform itself ended up being rather horrible, even though i omitted some cases. Surely there is some infrastructure that can help clean this up that i missed? https://rise4fun.com/Alive/3Ou The initial commit (rL339610) was reverted, since the first assert was being triggered. The @positive_with_extra_and test now has coverage for that case. Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: RKSimon, erichkeane, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D50465 llvm-svn: 339621
* [SimplifyLibCalls] don't drop fast-math-flags on trig reflection folds ↵Sanjay Patel2018-08-131-1/+6
| | | | | | | | | | (retry r339608) Even though this code is below a function called optimizeFloatingPointLibCall(), we apparently can't guarantee that we're dealing with FPMathOperators, so bail out immediately if that's not true. llvm-svn: 339618
* Revert "[InstCombine] Optimize redundant 'signed truncation check pattern'."Roman Lebedev2018-08-131-128/+0
| | | | | | | | | At least one buildbot was able to actually trigger that assert on the top of the function. Will investigate. This reverts commit r339610. llvm-svn: 339612
* [InstCombine] Optimize redundant 'signed truncation check pattern'.Roman Lebedev2018-08-131-0/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This comes with `Implicit Conversion Sanitizer - integer sign change` (D50250): ``` signed char test(unsigned int x) { return x; } ``` `clang++ -fsanitize=implicit-conversion -S -emit-llvm -o - /tmp/test.cpp -O3` * Old: {F6904292} * With this patch: {F6904294} General pattern: X & Y Where `Y` is checking that all the high bits (covered by a mask `4294967168`) are uniform, i.e. `%arg & 4294967168` can be either `4294967168` or `0` Pattern can be one of: %t = add i32 %arg, 128 %r = icmp ult i32 %t, 256 Or %t0 = shl i32 %arg, 24 %t1 = ashr i32 %t0, 24 %r = icmp eq i32 %t1, %arg Or %t0 = trunc i32 %arg to i8 %t1 = sext i8 %t0 to i32 %r = icmp eq i32 %t1, %arg This pattern is a signed truncation check. And `X` is checking that some bit in that same mask is zero. I.e. can be one of: %r = icmp sgt i32 %arg, -1 Or %t = and i32 %arg, 2147483648 %r = icmp eq i32 %t, 0 Since we are checking that all the bits in that mask are the same, and a particular bit is zero, what we are really checking is that all the masked bits are zero. So this should be transformed to: %r = icmp ult i32 %arg, 128 https://rise4fun.com/Alive/3Ou Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: RKSimon, erichkeane, vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D50465 llvm-svn: 339610
* revert r339608 - [SimplifyLibCalls] don't drop fast-math-flags on trig ↵Sanjay Patel2018-08-131-3/+1
| | | | | | | | | reflection folds Can't set the builder flags without knowing this is an FPMathOperator. I'll add a test for that and try again. llvm-svn: 339609
* [SimplifyLibCalls] don't drop fast-math-flags on trig reflection foldsSanjay Patel2018-08-131-1/+3
| | | | llvm-svn: 339608
* [SimplifyLibCalls] add reflection fold for -sin(-x) (PR38458)Sanjay Patel2018-08-131-15/+27
| | | | | | | | | | This is a very partial fix for the reported problem. I suspect we do not get this fold in most motivating cases because most of the time, the libcall would have been replaced by an intrinsic, and that optimization is handled elsewhere...but maybe it should be handled here? llvm-svn: 339604
* [CodeGen] Fix assert in SelectionDAG::computeKnownBitsScott Linder2018-08-131-2/+2
| | | | | | | | | | Fix SelectionDAG::computeKnownBits asserting when handling EXTRACT_SUBVECTOR when zero extending the demanded elements mask if it is already as long as the source vector. Differential Revision: https://reviews.llvm.org/D49574 llvm-svn: 339600
* [X86][BtVer2] Use NoSchedPredicate to model default transitions in variant ↵Andrea Di Biagio2018-08-131-8/+8
| | | | | | scheduling classes. NFC. llvm-svn: 339589
* [SimplifyLibCalls] reduce code for optimizeCos; NFCISanjay Patel2018-08-131-9/+8
| | | | llvm-svn: 339588
* [InstCombine] Limit simplifyAllocaArraySize constant folding to values that ↵Simon Pilgrim2018-08-131-24/+26
| | | | | | | | fit into a uint64_t Fixes OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5223 llvm-svn: 339584
* [itanium demangler] Add llvm::itaniumFindTypesInMangledName()Erik Pilkington2018-08-131-1/+15
| | | | | | | | | | | | This function calls a callback whenever a <type> is parsed. This is necessary to implement FindAlternateFunctionManglings in LLDB, which uses a similar hack in FastDemangle. Once that function has been updated to use this version, FastDemangle can finally be removed. Differential revision: https://reviews.llvm.org/D50586 llvm-svn: 339580
* [SLC] Expand simplification of pow() for vector typesEvandro Menezes2018-08-131-40/+37
| | | | | | | | Also consider vector constants when simplifying `pow()`. Differential revision: https://reviews.llvm.org/D50035 llvm-svn: 339578
* [Hexagon] Silence -Wuninitialized warning from GCC 5.4, NFCKrzysztof Parzyszek2018-08-131-0/+4
| | | | | | | | Patch by Kim Gräsman. Differential Revision: https://reviews.llvm.org/D50623 llvm-svn: 339576
* Revert "[Sparc] Add support for the cycle counter available in GR740"Daniel Cederman2018-08-135-21/+2
| | | | | | | It breaks when using EXPENSIVE_CHECKS with the error message "Bad machine code: Using an undefined physical register". llvm-svn: 339570
OpenPOWER on IntegriCloud