summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Reapply "[DemandedBits] Use SetVector for Worklist"Nikita Popov2019-01-121-7/+6
| | | | | | | | | | | | | | | | DemandedBits currently uses a simple vector for the worklist, which means that instructions may be inserted multiple times into it. Especially in combination with the deep lattice, this may cause instructions too be recomputed very often. To avoid this, switch to a SetVector. Reapplying with a smaller number of inline elements in the SmallSetVector, to avoid running into the SmallDenseMap issue described in D56455. Differential Revision: https://reviews.llvm.org/D56362 llvm-svn: 350997
* [X86] Remove X86ISD::SELECT as its no longer used by any of our intrinsic ↵Craig Topper2019-01-123-3/+1
| | | | | | lowering. llvm-svn: 350995
* [X86] Add ISD node for masked version of CVTPS2PH.Craig Topper2019-01-125-22/+59
| | | | | | | | | | The 128-bit input produces 64-bits of output and fills the upper 64-bits with 0. The mask only applies to the lower elements. But we can't represent this with a vselect like we normally do. This also avoids the need to have a special X86ISD::SELECT when avx512bw isn't enabled since vselect v8i16 isn't legal there. Fixes another instruction for PR34877. llvm-svn: 350994
* [RISCV] Introduce codegen patterns for RV64M-only instructionsAlex Bradbury2019-01-122-5/+52
| | | | | | | | | | | | | | | | | | As discussed on llvm-dev <http://lists.llvm.org/pipermail/llvm-dev/2018-December/128497.html>, we have to be careful when trying to select the *w RV64M instructions. i32 is not a legal type for RV64 in the RISC-V backend, so operations have been promoted by the time they reach instruction selection. Information about whether the operation was originally a 32-bit operations has been lost, and it's easy to write incorrect patterns. Similarly to the variable 32-bit shifts, a DAG combine on ANY_EXTEND will produce a SIGN_EXTEND if this is likely to result in sdiv/udiv/urem being selected (and so save instructions to sext/zext the input operands). Differential Revision: https://reviews.llvm.org/D53230 llvm-svn: 350993
* [RISCV] Add patterns for RV64I SLLW/SRLW/SRAW instructionsAlex Bradbury2019-01-122-1/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | This restores support for selecting the SLLW/SRLW/SRAW instructions, which was removed in rL348067 as the previous patterns made some unsafe assumptions. Also see the related llvm-dev discussion <http://lists.llvm.org/pipermail/llvm-dev/2018-December/128497.html> Ultimately I didn't introduce a custom SelectionDAG node, but instead added a DAG combine that inserts an AssertZext i5 on the shift amount for an i32 variable-length shift and also added an ANY_EXTEND DAG-combine which will instead produce a SIGN_EXTEND for an i32 variable-length shift, increasing the opportunity to safely select SLLW/SRLW/SRAW. There are obviously different ways of addressing this (a number discussed in the llvm-dev thread), so I'd welcome further feedback and comments. Note that there are now some cases in test/CodeGen/RISCV/rv64i-exhaustive-w-insts.ll where sraw/srlw/sllw is selected even though sra/srl/sll could be used without any extra instructions. Given both are semantically equivalent, there doesn't seem a good reason to prefer one vs the other. Given that would require more logic to still select sra/srl/sll in those cases, I've left it preferring the *w variants. Differential Revision: https://reviews.llvm.org/D56264 llvm-svn: 350992
* [X86] Remove unnecessary code from getMaskNode.Craig Topper2019-01-121-5/+1
| | | | | | We no longer need to extend mask scalars before bitcasting them to vXi1. This was only needed for the truncate intrinsics. And was really a bug in our lowering of them. llvm-svn: 350991
* [X86] When lowering v1i1/v2i1/v4i1/v8i1 load/store with avx512f, but not ↵Craig Topper2019-01-122-7/+11
| | | | | | | | | | avx512dq, use v16i1 as the intermediate mask type instead of v8i1. We still use i8 for the load/store type. So we need to convert to/from i16 to around the mask type. By doing this we get an i8->i16 extload which we can then pattern match to a KMOVW if the access is aligned. llvm-svn: 350989
* [X86] Change some patterns that select MOVZX16rm8 to instead select ↵Craig Topper2019-01-121-3/+6
| | | | | | | | MOVZX32rm8 and extract the subregister. This should be a shorter encoding and is consistent with what we do for zext i8->i16 llvm-svn: 350988
* [ARM] Fix typoEvandro Menezes2019-01-121-1/+0
| | | | | | Fix typo in r350952. llvm-svn: 350986
* [X86] Add ISD nodes for masked truncate so we can properly represent when ↵Craig Topper2019-01-125-150/+305
| | | | | | | | | | | | the output has more elements than the input due to needing to be 128 bits. We can't properly represent this with a vselect since the upper elements of the result are supposed to be zeroed regardless of the mask. This also reuses the new nodes even when the result type fits in 128 bits if the input is q/d and the result is w/b since vselect w/b using k-register condition isn't legal without avx512bw. Currently we're doing this even when avx512bw is enabled, but I might change that. This fixes some of PR34877 llvm-svn: 350985
* [AArch64] Improve Exynos predicatesEvandro Menezes2019-01-111-3/+12
| | | | | | | Expand the predicate using shifted arithmetic and logic instructions to also consider the respective not shifted instructions. llvm-svn: 350976
* [ConstantFolding] Fold undef for integer intrinsicsNikita Popov2019-01-111-63/+114
| | | | | | | | | | | | | | | | | | | This fixes https://bugs.llvm.org/show_bug.cgi?id=40110. This implements handling of undef operands for integer intrinsics in ConstantFolding, in particular for the bitcounting intrinsics (ctpop, cttz, ctlz), the with.overflow intrinsics, the saturating math intrinsics and the funnel shift intrinsics. The undef behavior follows what InstSimplify does for the general cas e of non-constant operands. For the bitcount intrinsics (where InstSimplify doesn't do undef handling -- there cannot be a combination of an undef + non-constant operand) I'm using a 0 result if the intrinsic is defined for zero and undef otherwise. Differential Revision: https://reviews.llvm.org/D55950 llvm-svn: 350971
* [X86] Fix incomplete handling of register-assigned variables in parsing.Nirav Dave2019-01-111-185/+205
| | | | | | | | | | | | | | Teach x86 assembly operand parsing to distinguish between assembler variable assigned to named registers and those assigned to immediate values. Reviewers: rnk, nickdesaulniers, void Subscribers: hiraditya, jyknight, llvm-commits Differential Revision: https://reviews.llvm.org/D56287 llvm-svn: 350966
* [AArch64] Add pipeline model for Exynos M4Evandro Menezes2019-01-112-1/+1006
| | | | | | Add the scheduling and cost model for Exynos M4. llvm-svn: 350960
* [AArch64] Create feature set for Exynos M4Evandro Menezes2019-01-112-1/+23
| | | | | | Complete the feature set for Exynos M4 and update test cases. llvm-svn: 350953
* [Legalizer] Use correct ValueType of SELECT_CC node during Float promotionPirama Arumuga Nainar2019-01-111-3/+3
| | | | | | | | | | | | | | | | | Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
* [LTO] Record whether LTOUnit splitting is enabled in indexTeresa Johnson2019-01-117-10/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Records in the module summary index whether the bitcode was compiled with the option necessary to enable splitting the LTO unit (e.g. -fsanitize=cfi, -fwhole-program-vtables, or -fsplit-lto-unit). The information is passed down to the ModuleSummaryIndex builder via a new module flag "EnableSplitLTOUnit", which is propagated onto a flag on the summary index. This is then used during the LTO link to check whether all linked summaries were built with the same value of this flag. If not, an error is issued when we detect a situation requiring whole program visibility of the class hierarchy. This is the case when both of the following conditions are met: 1) We are performing LowerTypeTests or Whole Program Devirtualization. 2) There are type tests or type checked loads in the code. Note I have also changed the ThinLTOBitcodeWriter to also gate the module splitting on the value of this flag. Reviewers: pcc Subscribers: ormris, mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D53890 llvm-svn: 350948
* [MergeFunc] Erase unused duplicate functions if they are discardableVedant Kumar2019-01-111-1/+1
| | | | | | | | | | MergeFunc only deletes unused duplicate functions if they have local linkage, but it should be safe to relax this to any "discardable if unused" linkage type. Differential Revision: https://reviews.llvm.org/D56574 llvm-svn: 350939
* [MergeFunc] Use Instruction::getFunction as a cleanup, NFCVedant Kumar2019-01-111-2/+2
| | | | llvm-svn: 350938
* [Jump Threading] Unfold a select insn that feeds a switch via a phi nodeEhsan Amiri2019-01-111-28/+70
| | | | | | | | | | | Currently when a select has a constant value in one branch and the select feeds a conditional branch (via a compare/ phi and compare) we unfold the select statement. This results in threading the conditional branch later on. Similar opportunity exists when a select (with a constant in one branch) feeds a switch (via a phi node). The patch unfolds select under this condition. A testcase is provided. llvm-svn: 350931
* [x86] allow insert/extract when matching horizontal opsSanjay Patel2019-01-111-3/+13
| | | | | | | | | | | | | | Previously, we limited this transform to cases where the extraction into the build vector happens from vectors of the same type as the build vector, but that's not required. There's a slight potential regression seen in the AVX512 result for phadd -- we're using the 256-bit flavor of the instruction now even though the 128-bit subset is sufficient. The same problem could already be seen in the AVX2 result. Follow-up patches will attempt to narrow that back down. llvm-svn: 350928
* Revert "[SelectionDAGBuilder] Refactor GetRegistersForValue. NFCI."Martin Storsjo2019-01-111-42/+60
| | | | | | | This reverts commit r350841, as it actually had functional changes and broke compilation. See PR40290. llvm-svn: 350921
* [X86] Change vXi1 extract_vector_elt lowering to be legal if the index is 0. ↵Craig Topper2019-01-112-23/+34
| | | | | | | | | | | | Add DAG combine to turn scalar_to_vector+extract_vector_elt into extract_subvector. We were lowering the last step extract_vector_elt to a bitcast+truncate. Change it to use an extract_vector_elt of index 0 instead. Add isel patterns to do the equivalent of what the bitcast would have done. Plus an isel pattern for an any_extend+extract to prevent some regressions. Finally add a DAG combine to turn v1i1 scalar_to_vector+extract_vector_elt of 0 into an extract_subvector. This fixes some of the regressions from D350800. llvm-svn: 350918
* [WebAssembly] Fix stack pointer store check in RegStackifyHeejin Ahn2019-01-101-13/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: We now use __stack_pointer global and global.get/global.set instruction. This fixes the checking routine for stack_pointer writes accordingly. This also fixes the existing __stack_pointer test in reg-stackify.ll: That test used to pass not because of __stack_pointer clashes but because the function `stackpointer_callee` was not marked as `readnone`, so it was assumed to possibly write to memory arbitraily, and `global.set` instruction was marked as `mayStore` in the .td definition, so they were identified as intervening writes. After we added `readnone` to its attribute, this test fails without this patch. Reviewers: dschuff, sunfish Subscribers: jgravelle-google, sbc100, llvm-commits Differential Revision: https://reviews.llvm.org/D56094 llvm-svn: 350906
* [MSP430] Minor fixes/improvements for assembler/disassemblerAnton Korobeynikov2019-01-103-2/+18
| | | | | | | | | | | | | * Teach AsmParser to recognize @rn in distination operand as 0(rn). * Do not allow Disassembler decoding instructions that have size more than a number of input bytes. * Fix UB in MSP430MCCodeEmitter. Patch by Kristina Bessonova! Differential Revision: https://reviews.llvm.org/D56547 llvm-svn: 350903
* [MSP430] Add missing instruction formsAnton Korobeynikov2019-01-101-9/+115
| | | | | | | | | | | * Add missing mm, [r|m]n, [r|m]p instruction forms. * Fix bit16mc instruction. Patch by Kristina Bessonova! Differential Revision: https://reviews.llvm.org/D56546 llvm-svn: 350902
* [WebAssembly] Add unimplemented-simd128 subtarget featureThomas Lively2019-01-109-35/+62
| | | | | | | | | | | | | | Summary: This is a third attempt, but this time we have vetted it on Windows first. The previous errors were due to an uninitialized class member. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D56560 llvm-svn: 350901
* [MachineCombiner][NFC] Prevent dereferencing past-the-end object in an MRI ↵Gerolf Hoflehner2019-01-101-0/+2
| | | | | | container llvm-svn: 350896
* [MemorySSA] Disable checkClobberSanity for SkipSelfWalker.Alina Sbirlea2019-01-101-1/+2
| | | | | | | | | Sanity will fail for this, since we're exploring getting a clobber further than the sanity check expects. Ideally we need to teach the sanity check to differentiate between the two walkers based on the SkipSelf bool in the query. llvm-svn: 350895
* [GVN] Update BlockRPONumber prior to use.Matt Davis2019-01-101-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The original patch addressed the use of BlockRPONumber by forcing a sequence point when accessing that map in a conditional. In short we found cases where that map was being accessed with blocks that had not yet been added to that structure. For context, I've kept the wall of text below, to what we are trying to fix, by always ensuring a updated BlockRPONumber. == Backstory == I was investigating an ICE (segfault accessing a DenseMap item). This failure happened non-deterministically, with no apparent reason and only on a Windows build of LLVM (from October 2018). After looking into the crashes (multiple core files) and running DynamoRio, the cores and DynamoRio (DR) log pointed to the same code in `GVN::performScalarPRE()`. The values in the map are unsigned integers, the keys are `llvm::BasicBlock*`. Our test case that triggered this warning and periodic crash is rather involved. But the problematic line looks to be: GVN.cpp: Line 2197 ``` if (BlockRPONumber[P] >= BlockRPONumber[CurrentBlock] && ``` To test things out, I cooked up a patch that accessed the items in the map outside of the condition, by forcing a sequence point between accesses. DynamoRio stopped warning of the issue, and the test didn't seem to crash after 1000+ runs. My investigation was on an older version of LLVM, (source from October this year). What it looks like was occurring is the following, and the assembly from the latest pull of llvm in December seems to confirm this might still be an issue; however, I have not witnessed the crash on more recent builds. Of course the asm in question is generated from the host compiler on that Windows box (not clang), but it hints that we might want to consider how we access the BlockRPONumber map in this conditional (line 2197, listed above). In any case, I don't think the host compiler is wrong, rather I think it is pointing out a possibly latent bug in llvm. 1) There is no sequence point for the `>=` operation. 2) A call to a `DenseMapBase::operator[]` can have the side effect of the map reallocating a larger store (more Buckets, via a call to `DenseMap::grow`). 3) It seems perfectly legal for a host compiler to generate assembly that stores the result of a call to `operator[]` on the stack (that's what my host compile of GVN.cpp is doing) . A second call to `operator[]` //might// encourage the map to 'grow' thus making any pointers to the map's store invalid. The `>=` compares the first and second values. If the first happens to be a pointer produced from operator[], it could be invalid when dereferenced at the time of comparison. The assembly generated from the Window's host compiler does show the result of the first access to the map via `operator[]` produces a pointer to an unsigned int. And that pointer is being stored on the stack. If a second call to the map (which does occur) causes the map to grow, that address (on the stack) is now invalid. Reviewers: t.p.northover, efriedma Reviewed By: efriedma Subscribers: efriedma, llvm-commits Differential Revision: https://reviews.llvm.org/D55974 llvm-svn: 350880
* Use MemorySSA in LICM to do sinking and hoisting.Alina Sbirlea2019-01-102-109/+252
| | | | | | | | | | | | | | | | | | Summary: Step 2 in using MemorySSA in LICM: Use MemorySSA in LICM to do sinking and hoisting, all under "EnableMSSALoopDependency" flag. Promotion is disabled. Enable flag in LICM sink/hoist tests to test correctness of this change. Moved one test which relied on promotion, in order to test all sinking tests. Reviewers: sanjoy, davide, gberry, george.burgess.iv Subscribers: llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D40375 llvm-svn: 350879
* [X86] Call SimplifyDemandedBits on conditions of X86ISD::SHRUNKBLENDCraig Topper2019-01-101-2/+10
| | | | | | | | | | This extends to combineVSelectToShrunkBlend to be able to resimplify SHRUNKBLENDS that have already been created. This should help some of the regressions from D56387 Differential Revision: https://reviews.llvm.org/D56421 llvm-svn: 350875
* [X86] Simplify the BRCOND handling for FCMP_UNE.Craig Topper2019-01-101-28/+11
| | | | | | | | | | Despite what the comment says, FCMP_UNE would be an OR not an AND. In the lowering code the first branch created still goes to the original destination. The second branch was exchanged to go to where the subsequent unconditional branch went. This is different than what we do for FCMP_OEQ where both branches that we create go to the original unconditional branch. As far as I can tell, I think this means we don't need to exchange the branch target with the unconditional branch for FCMP_UNE at all. Differential Revision: https://reviews.llvm.org/D56309 llvm-svn: 350873
* [DAGCombiner] simplify code; NFCSanjay Patel2019-01-101-11/+11
| | | | llvm-svn: 350844
* [SelectionDAGBuilder] Refactor GetRegistersForValue. NFCI.Nirav Dave2019-01-101-60/+42
| | | | llvm-svn: 350841
* [SelectionDAGBuilder] Fix formatting. NFC.Nirav Dave2019-01-101-1/+2
| | | | llvm-svn: 350839
* [AMDGPU] Fix dwordx3/southern-islands failures.Neil Henning2019-01-102-4/+10
| | | | | | | | | | | This commit fixes the dwordx3/southern-islands failures that were found in bugzilla https://bugs.llvm.org/show_bug.cgi?id=40129, by not generating the dwordx3 variants of load/store instructions that were added to the ISA after southern islands. Differential Revision: https://reviews.llvm.org/D56434 llvm-svn: 350838
* [SelectionDAGBuilder] Refactor visitInlineAsm. NFC.Nirav Dave2019-01-101-45/+24
| | | | llvm-svn: 350837
* [opaque pointer types] Remove some calls to generic Type subtype accessors.James Y Knight2019-01-1012-59/+47
| | | | | | | | | | | | That is, remove many of the calls to Type::getNumContainedTypes(), Type::subtypes(), and Type::getContainedType(N). I'm not intending to remove these accessors -- they are useful/necessary in some cases. However, removing the pointee type from pointers would potentially break some uses, and reducing the number of calls makes it easier to audit. llvm-svn: 350835
* [RISCV][MC] Add support for evaluating constant symbols as immediatesAlex Bradbury2019-01-101-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | This further improves compatibility with GNU as, allowing input such as the following to be assembled: .equ CONST, 0x123456 li a0, CONST addi a0, a0, %lo(CONST) .equ CONST, 1 slli a0, a0, CONST Note that we don't have perfect compatibility with gas, as it will avoid emitting a relocation in this case: addi a0, a0, %lo(CONST2) .equ CONST2, 0x123456 Thanks to Shiva Chen for suggesting a better way to approach this during review. Differential Revision: https://reviews.llvm.org/D52298 llvm-svn: 350831
* [x86] fix remaining miscompile bug in horizontal binop matching (PR40243)Sanjay Patel2019-01-101-5/+8
| | | | | | | | | | | When we use the partial-matching function on a 128-bit chunk, we must account for the possibility that we've matched undef halves of the original source vectors, so the outputs may need to be reset. This should allow closing PR40243: https://bugs.llvm.org/show_bug.cgi?id=40243 llvm-svn: 350830
* [x86] fix horizontal binop matching for 256-bit vectors (PR40243)Sanjay Patel2019-01-101-70/+169
| | | | | | | | | | | | | | | | | This is a partial fix for: https://bugs.llvm.org/show_bug.cgi?id=40243 ...as seen in the integer test, we still need to correct the result when using the existing (old) horizontal op matching function because it does not model the way x86 256-bit horizontal ops return results (each 128-bit half is its own horizontal-op). A potential follow-up change for that is discussed in the bug report - see also D56490. This generally duplicates a lot of the existing matching code, but we can't just remove that without introducing regressions, so the existing code is renamed and used less often. Follow-ups may try to reduce that overlap. Differential Revision: https://reviews.llvm.org/D56450 llvm-svn: 350826
* [AArch64] Fix operation actions for FP16 vector intrinsicsBryan Chan2019-01-101-20/+22
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch changes the legalization action for some half-precision floating- point vector intrinsics (FSIN, FLOG, etc.) from Promote to Expand. These ops are not supported in hardware for half-precision vectors, but promotion is not always possible (for v8f16 operands). Changing the action to Expand fixes an assertion failure in the legalizer when the frontend produces such ops. In addition, a quick microbenchmark shows that, in the v4f16 case, expanding introduces fewer spills and is therefore slightly faster than promoting. Reviewers: t.p.northover, SjoerdMeijer Reviewed By: SjoerdMeijer Subscribers: javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D56296 llvm-svn: 350825
* [MCA] Fix wrong definition of ResourceUnitMask in DefaultResourceStrategy.Andrea Di Biagio2019-01-105-15/+36
| | | | | | | | | | | | | | Field ResourceUnitMask was incorrectly defined as a 'const unsigned' mask. It should have been a 64 bit quantity instead. That means, ResourceUnitMask was always implicitly truncated to a 32 bit quantity. This issue has been found by inspection. Surprisingly, that bug was latent, and it never negatively affected any existing upstream targets. This patch fixes the wrong definition of ResourceUnitMask, and adds a bunch of extra debug prints to help debugging potential issues related to invalid processor resource masks. llvm-svn: 350820
* [ARM] Fix for verifier buildbotSam Parker2019-01-101-5/+5
| | | | | | | Copy the MachineOperand first and then change the flags instead of making a copy. llvm-svn: 350811
* [LoopUnroll] add parsing for unroll parameters in -passes pipelineFedor Sergeev2019-01-102-2/+104
| | | | | | | | | | | | | | | | | | | | | | | Allow to specify loop-unrolling with optional parameters explicitly spelled out in -passes pipeline specification. Introducing somewhat generic way of specifying parameters parsing via FUNCTION_PASS_PARAMETRIZED pass registration. Syntax of parametrized unroll pass name is as follows: 'unroll<' parameter-list '>' Where parameter-list is ';'-separate list of parameter names and optlevel optlevel: 'O[0-3]' parameter: { 'partial' | 'peeling' | 'runtime' | 'upperbound' } negated: 'no-' parameter Example: -passes=loop(unroll<O3;runtime;no-upperbound>) this invokes LoopUnrollPass configured with OptLevel=3, Runtime, no UpperBound, everything else by default. llvm-svn: 350808
* [ARM] Size reduce teq to eorsSam Parker2019-01-101-3/+29
| | | | | | | | | | | Add t2TEQrr to the map of instructions with can be reduced down into a T1 instruction. This is a special case because TEQ just sets the CPSR and doesn't write to a GPR, which is not the case for EOR. So, we need to ensure that the EOR can write to the first operand. Differential Revision: https://reviews.llvm.org/D56255 llvm-svn: 350801
* [X86] Disable DomainReassignment pass when AVX512BW is disabled to avoid ↵Craig Topper2019-01-101-1/+4
| | | | | | | | | | | | | | | | | | | | | | | injecting VK32/VK64 references into the MachineIR Summary: This pass replaces GR8/GR16/GR32/GR64 with their equivalent sized mask register classes. But VK32/VK64 aren't legal without AVX512BW. Apparently this mostly appears to work if the register coalescer is able to remove the VK32/VK64 register class reference. Or if we don't ever spill it. But there's no guarantee of that. Another Intel employee managed to trigger a crash due to this with ISPC. Unfortunately, I've lost the test case he sent me at the time. I'm trying to get him to reproduce it for me. I'd like to get this in before 8.0 branches since its a little scary. The regressions here are unfortunate, but I think we can make some improvements to DAG combine, load folding, etc. to fix them. Just not sure if we can get that done for 8.0. Fixes PR39741 Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56460 llvm-svn: 350800
* Recommit "[PowerPC] Fix assert from machine verify pass that unmatched ↵Zi Xuan Wu2019-01-101-13/+24
| | | | | | | | | | register class about fcmp selection in fast-isel" This re-commit r350685. Differential Revision: https://reviews.llvm.org/D55686 llvm-svn: 350799
* [AArch64] Emit the correct MCExpr relocations specifiers like VK_ABS_G0, etcMandeep Singh Grang2019-01-103-4/+40
| | | | | | | | | | | | | | | | Summary: D55896 and D56029 add support to emit fixups for :abs_g0: , :abs_g1_s: , etc. This patch adds the necessary enums and MCExpr needed for lowering these. Reviewers: rnk, mstorsjo, efriedma Reviewed By: efriedma Subscribers: javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D56037 llvm-svn: 350798
OpenPOWER on IntegriCloud