summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [NFC][TTI] Add Alignment for isLegalMasked[Gather/Scatter]Anna Welker2019-12-181-6/+8
| | | | | | | Add an extra parameter so alignment can be taken under consideration in gather/scatter legalization. Differential Revision: https://reviews.llvm.org/D71610
* [X86] Add calculation for elements in structures in getting uniform base for ↵Wang, Pengfei2019-12-181-6/+28
| | | | | | | | | | | | | | | the Gather/Scatter intrinsic. Summary: Add calculation for elements in structures in getting uniform base for the Gather/Scatter intrinsic. Reviewers: craig.topper, c-rhodes, RKSimon Subscribers: hiraditya, llvm-commits, annita.zhang, LuoYuanke Tags: #llvm Differential Revision: https://reviews.llvm.org/D71442
* [FPEnv][LegalizeTypes] Make ScalarizeVecOp_STRICT_FP_ROUND do its own ↵Craig Topper2019-12-171-1/+7
| | | | | | | | | | | | replacements and return SDValue() The caller will assert for nodes with more than 2 results unless we return a null SDValue. I tried to test this by copying an AArch64 test for ScalarizeVecOp_FP_ROUND. While it did hit the assert and this commited fixed that. It also hit a later problem that couldn't be fixed without adding strict FP support to AArch64.
* [FPEnv][LegalizeTypes][LegalizeDAG][AArch64] Few fixes/improvements for ↵Craig Topper2019-12-174-2/+22
| | | | | | | | | | | | | | | | legalizing fp<->int conversion nodes. This started with adding a test to support get code coverage on ScalarizeVecOp_UnaryOp_StrictFP by copying an existing AArch64 test and using constrained sitofp/uitofp intrinsics. This found 3 separate issues: -ScalarizeVecOp_UnaryOp_StrictFP needs to do its own replacement because the caller can't handle replacing multiple results. -Missing integer promotion support for sitofp/uitofp -Chain result not always assigned in ExpandLegalINT_TO_FP. Committing them together so I can add the test case.
* Recommit "[DebugInfo] Refactored macro related generation,Sourabh Singh Tomar2019-12-182-19/+9
| | | | | | | | | | | | | | | | | | added a test case for macinfo.dwo emission." This was reverted in caa412090666c10f854322cdc701c1cbf8ed726e, since it was causing an assertion failure on Windows bots. This revision is revised to fix that. Original commit message - [DebugInfo] Refactored macro related generation, added a test case for macinfo.dwo emission. Reviewers: dblaikie, aprantl, jini.susan.george Tags: #debug-info #llvm Differential Revision: https://reviews.llvm.org/D71008
* [SDAG] adjust isNegatibleForFree calculation to avoid crashingSanjay Patel2019-12-171-1/+8
| | | | | | | | | | | | | | | | | | | | This is an alternate fix for the bug discussed in D70595. This also includes minimal tests for other in-tree targets to show the problem more generally. We check the number of uses as a predicate for whether some value is free to negate, but that use count can change as we rewrite the expression in getNegatedExpression(). So something that was marked free to negate during the cost evaluation phase becomes not free to negate during the rewrite phase (or the inverse - something that was not free becomes free). This can lead to a crash/assert because we expect that everything in an expression that is negatible to be handled in the corresponding code within getNegatedExpression(). This patch adds a hack to work-around the case where we probably no longer detect that either multiply operand of an FMA isNegatibleForFree which is assumed to be true when we started rewriting the expression. Differential Revision: https://reviews.llvm.org/D70975
* Revert "[SDAG] remove use restriction in isNegatibleForFree() when called ↵Sanjay Patel2019-12-171-8/+1
| | | | | | | from getNegatedExpression()" This reverts commit 36b1232ec5f370ab9fe8fcff0458d2fca5ca9b7f. Need to adjust commit message - that was a leftover from the earlier version.
* [SDAG] remove use restriction in isNegatibleForFree() when called from ↵Sanjay Patel2019-12-171-1/+8
| | | | | | | | | | | | | | | | | | | | | | getNegatedExpression() This is an alternate fix for the bug discussed in D70595. This also includes minimal tests for other in-tree targets to show the problem more generally. We check the number of uses as a predicate for whether some value is free to negate, but that use count can change as we rewrite the expression in getNegatedExpression(). So something that was marked free to negate during the cost evaluation phase becomes not free to negate during the rewrite phase (or the inverse - something that was not free becomes free). This can lead to a crash/assert because we expect that everything in an expression that is negatible to be handled in the corresponding code within getNegatedExpression(). This patch adds a hack to work-around the case where we probably no longer detect that either multiply operand of an FMA isNegatibleForFree which is assumed to be true when we started rewriting the expression. Differential Revision: https://reviews.llvm.org/D70975
* [DAGCombiner] Add node back in the worklist in topological order in ↵Amaury Séchet2019-12-171-2/+1
| | | | | | | | | | | | | | | | | CommitTargetLoweringOpt Summary: Right now, DAGCombiner process the nodes in an iplementation defined order. This tends to be fragile as optimisation may or may not kick in depending on the traversal order. This is part of a larger effort to get the DAGCombiner to process its node in topological order. Reviewers: craig.topper, efriedma, RKSimon, lebedev.ri Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70921
* Revert "Honor -fuse-init-array when os is not specified on x86"Mitch Phillips2019-12-171-1/+0
| | | | | | | This reverts commit aa5ee8f244441a8ea103a7e0ed8b6f3e74454516. This change broke the sanitizer buildbots. See comments at the patchset (https://reviews.llvm.org/D71360) for more information.
* This adds constrained intrinsics for the signed and unsigned conversionsKevin P. Neal2019-12-176-52/+236
| | | | | | | | | of integers to floating point. This includes some of Craig Topper's changes for promotion support from D71130. Differential Revision: https://reviews.llvm.org/D69275
* PostRA Machine Sink should take care of COPY defining register that is a ↵alex-t2019-12-171-3/+7
| | | | | | sub-register by another COPY source operand Differential Revision: https://reviews.llvm.org/D71132
* Resubmit "[Alignment][NFC] Deprecate CreateMemCpy/CreateMemMove"Guillaume Chatelet2019-12-171-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: This is a resubmit of D71473. This patch introduces a set of functions to enable deprecation of IRBuilder functions without breaking out of tree clients. Functions will be deprecated one by one and as in tree code is cleaned up. This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: aaron.ballman, courbet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71547
* [ObjC][DWARF] Emit DW_AT_APPLE_objc_direct for methods marked as ↵Raphael Isemann2019-12-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | __attribute__((objc_direct)) Summary: With DWARF5 it is no longer possible to distinguish normal methods and methods with `__attribute__((objc_direct))` by just looking at the debug information as they are both now children of the of the DW_TAG_structure_type that defines them (before only the `__attribute__((objc_direct))` methods were children). This means that in LLDB we are no longer able to create a correct Clang AST of a module by just looking at the debug information. Instead we would need to call the Objective-C runtime to see which of the methods have a `__attribute__((objc_direct))` and then add the attribute to our own Clang AST depending on what the runtime returns. This would mean that we either let the module AST be dependent on the Objective-C runtime (which doesn't seem right) or we retroactively add the missing attribute to the imported AST in our expressions. A third option is to annotate methods with `__attribute__((objc_direct))` as `DW_AT_APPLE_objc_direct` which is what this patch implements. This way LLDB doesn't have to call the runtime for any `__attribute__((objc_direct))` method and the AST in our module will already be correct when we create it. Reviewers: aprantl, SouraVX Reviewed By: aprantl Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D71201
* [LegalizeTypes] Pre-size the SmallVectors in ScalarizeVecRes_StrictFPOp and ↵Craig Topper2019-12-161-9/+9
| | | | | | SplitVecRes_StrictFPOp so we don't have to call push_back. NFCI This avoids grow checking/handling in each iteration of the loop.
* [LegalizeTypes] Remove ScalarizeVecRes_STRICT_FP_ROUND in favor of just ↵Craig Topper2019-12-162-16/+0
| | | | | | | | using ScalarizeVecRes_StrictFPOp. NFCI It looks like ScalarizeVecRes_StrictFPOp can handle a variable number of arguments with scalar and vector types so it should be sufficient.
* [LegalizeTypes] Remove the call to SplitVecRes_UnaryOp from ↵Craig Topper2019-12-161-29/+0
| | | | | | | | SplitVecRes_StrictFPOp. NFCI It doesn't seem to do anything that SplitVecRes_StrictFPOp can't do. SplitVecRes_StrictFPOp already handles nodes with a variable number of arguments and a mix of scalar and vector arguments.
* [SelectionDAG] Add the fpexcept flag to the SelectionDAG dumping output so ↵Craig Topper2019-12-161-0/+3
| | | | | | | | we can better see when its not propagating. We're currently losing this flag in type legalization and probably other places when we expand strict fp nodes. This will make reading logs easier.
* [NFC][llvm][MIRVRegNamerUtils] Moving some switch cases and altering comments.Puyan Lotfi2019-12-161-5/+5
|
* [llvm][MIRVRegNamerUtils] Adding hashing on CImm / FPImm MachineOperands.Puyan Lotfi2019-12-161-2/+7
| | | | | | | | | | | | | | | | | This patch makes it so that cases where multiple instructions that differ only in their ConstantInt or ConstantFP MachineOperand values no longer collide. For instance: %0:_(s1) = G_CONSTANT i1 true %1:_(s1) = G_CONSTANT i1 false %2:_(s32) = G_FCONSTANT float 1.0 %3:_(s32) = G_FCONSTANT float 0.0 Prior to this patch the first two instructions would collide together. Also, the last two G_FCONSTANT instructions would also collide. Now they will no longer collide. Differential Revision: https://reviews.llvm.org/D71558
* Honor -fuse-init-array when os is not specified on x86Kamlesh Kumar2019-12-161-0/+1
| | | | | | | | | | | | | | | | | | | | | Currently -fuse-init-array option is not effective when target triple does not specify os, on x86,x86_64. i.e. // -fuse-init-array is not honored. $ clang -target i386 -fuse-init-array test.c -S // -fuse-init-array is honored. $ clang -target i386-linux -fuse-init-array test.c -S This patch fixes first case. And does cleanup. Reviewers: rnk, craig.topper, fhahn, echristo Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71360
* Revert "[Alignment][NFC] Deprecate CreateMemCpy/CreateMemMove"Guillaume Chatelet2019-12-161-2/+2
| | | | This reverts commit 181ab91efc9fb08dedda10a2fbc5fccb83ce8799.
* [Alignment][NFC] Deprecate CreateMemCpy/CreateMemMoveGuillaume Chatelet2019-12-161-2/+2
| | | | | | | | | | | | | | | | | | Summary: This patch introduces a set of functions to enable deprecation of IRBuilder functions without breaking out of tree clients. Functions will be deprecated one by one and as in tree code is cleaned up. This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71473
* [CodegenPrepare] Guard against degenerate branchesValentin Churavy2019-12-161-0/+4
| | | | | | | | | | | | | | | Summary: Guard against a potential crash observed in https://github.com/JuliaLang/julia/issues/32994#issuecomment-524249628 If two branches are collapsed we can encounter a degenerate conditional branch `TBB==FBB`. The subsequent code assumes that they differ, so we exit out early. Reviewers: ributzka, spatel Subscribers: loladiro, dexonsmith, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66657
* [DAG] Add SimplifyDemandedBits support for BSWAPSanjay Patel2019-12-151-0/+10
| | | | | | | | | This exposes a shortcoming for AArch64, and that is tracked by PR40881: https://bugs.llvm.org/show_bug.cgi?id=40881 Patch by: @RKSimon (Simon Pilgrim) Differential Revision: https://reviews.llvm.org/D58017
* [LegalizeTypes] Teach BitcastToInt_ATOMIC_SWAP to only create FP16_TO_FP ↵Craig Topper2019-12-141-4/+9
| | | | | | | | | when called from PromoteFloatResult. There's also a call from SoftenFloatResult that should not be promoted. The change test case would fail with the new RUN line prior to this change.
* [LegalizeTypes] In PromoteFloatOp_SETCC, don't both querying for ↵Craig Topper2019-12-141-2/+1
| | | | | | | transforming the result type. The result type is already legal, is doesnt' need to be transformed.
* [NFC][llvm][MIRVRegNamerUtils] Refactoring GetHashableMO into switch-statement.Puyan Lotfi2019-12-141-7/+34
| | | | | | | | | | | This refactors the if-statements handling the hashing of various MachineOperand types into a switch-statement. The purpose is to cover all the basis for all MachineOperand types while being very deliberate about which MachineOperand types we are not handling and why (better added comments). This patch is a NFC redo of https://reviews.llvm.org/D71396. Much of the changes present in D71396 will come in smaller follow-up patches that will add support for hashing the MachineOperand types that aren't covered piece-meal with tests for each new case.
* [Legalizer] Making artifact combining order-independentRoman Tereshin2019-12-131-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Legalization algorithm is complicated by two facts: 1) While regular instructions should be possible to legalize in an isolated, per-instruction, context-free manner, legalization artifacts can only be eliminated in pairs, which could be deeply, and ultimately arbitrary nested: { [ () ] }, where which paranthesis kind depicts an artifact kind, like extend, unmerge, etc. Such structure can only be fully eliminated by simple local combines if they are attempted in a particular order (inside out), or alternatively by repeated scans each eliminating only one innermost pair, resulting in O(n^2) complexity. 2) Some artifacts might in fact be regular instructions that could (and sometimes should) be legalized by the target-specific rules. Which means failure to eliminate all artifacts on the first iteration is not a failure, they need to be tried as instructions, which may produce more artifacts, including the ones that are in fact regular instructions, resulting in a non-constant number of iterations required to finish the process. I trust the recently introduced termination condition (no new artifacts were created during as-a-regular-instruction-retrial of artifacts not eliminated on the previous iteration) to be efficient in providing termination, but only performing the legalization in full if and only if at each step such chains of artifacts are successfully eliminated in full as well. Which is currently not guaranteed, as the artifact combines are applied only once and in an arbitrary order that has to do with the order of creation or insertion of artifacts into their worklist, which is a no particular order. In this patch I make a small change to the artifact combiner, making it to re-insert into the worklist immediate (modulo a look-through copies) artifact users of each vreg that changes its definition due to an artifact combine. Here the first scan through the artifacts worklist, while not being done in any guaranteed order, only needs to find the innermost pair(s) of artifacts that could be immediately combined out. After that the process follows def-use chains, making them shorter at each step, thus combining everything that can be combined in O(n) time. Reviewers: volkan, aditya_nandakumar, qcolombet, paquette, aemerson, dsanders Reviewed By: aditya_nandakumar, paquette Tags: #llvm Differential Revision: https://reviews.llvm.org/D71448
* [Legalizer] Refactoring out legalizeMachineFunctionRoman Tereshin2019-12-131-49/+66
| | | | | | | | and introducing new unittests/CodeGen/GlobalISel/LegalizerTest.cpp relying on it to unit test the entire legalizer algorithm (including the top-level main loop). See also https://reviews.llvm.org/D71448
* [Legalizer] More detailed debugging printing in main loopRoman Tereshin2019-12-131-1/+7
|
* [NFC] Use SelectionDAG::getMemBasePlusOffset() instead of getNode(ISD::ADD)Alex Richardson2019-12-137-55/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: To find potential opportunities to use getMemBasePlusOffset() I looked at all ISD::ADD uses found with the regex getNode\(ISD::ADD,.+,.+Ptr in lib/CodeGen/SelectionDAG. If this patch is accepted I will convert the files in the individual backends too. The motivation for this change is our out-of-tree CHERI backend (https://github.com/CTSRD-CHERI/llvm-project). We use a separate register type to store pointers (128-bit capabilities, which are effectively unforgeable and monotonic fat pointers). These capabilities permit a reduced set of operations and therefore use a separate ValueType (iFATPTR). to represent pointers implemented as capabilities. Therefore, we need to avoid using ISD::ADD for our patterns that operate on pointers and need to use a function that chooses ISD::ADD or a new ISD::PTRADD opcode depending on the value type. We originally added a new DAG.getPointerAdd() function, but after this patch series we can modify the implementation of getMemBasePlusOffset() instead. Avoiding direct uses of ISD::ADD for pointer types will significantly reduce the amount of assertion/instruction selection failures for us in future upstream merges. Reviewers: spatel Reviewed By: spatel Subscribers: merge_guards_bot, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71207
* [NFC] Implement SelectionDAG::getObjectPtrOffset() using getMemBasePlusOffset()Alex Richardson2019-12-131-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is preparatory work to use this helper functions in more places. In order to make this change, getMemBasePlusOffset() has been extended to also take a SDNodeFlags parameter. The motivation for this change is our out-of-tree CHERI backend (https://github.com/CTSRD-CHERI/llvm-project). We use a separate register type to store pointers (128-bit capabilities, which are effectively unforgeable and monotonic fat pointers). These capabilities permit a reduced set of operations and therefore use a separate ValueType (iFATPTR). to represent pointers implemented as capabilities. Therefore, we need to avoid using ISD::ADD for our patterns that operate on pointers and need to use a function that chooses ISD::ADD or a new ISD::PTRADD opcode depending on the value type. We originally added a new DAG.getPointerAdd() function, but after this patch series we can modify the implementation of getMemBasePlusOffset() instead. Avoiding direct uses of ISD::ADD for pointer types will significantly reduce the amount of assertion/instruction selection failures for us in future upstream merges. Reviewers: spatel Reviewed By: spatel Subscribers: merge_guards_bot, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71206
* [NFC] Add a SDValue overload for SelectionDAG::getMemBasePlusOffset()Alex Richardson2019-12-131-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is preparatory work to use this helper functions in more places. Currently the function only allows integer constants offsets, but there are cases where we can use an existing SDValue parameter. The motivation for this change is our out-of-tree CHERI backend (https://github.com/CTSRD-CHERI/llvm-project). We use a separate register type to store pointers (128-bit capabilities, which are effectively unforgeable and monotonic fat pointers). These capabilities permit a reduced set of operations and therefore use a separate ValueType (iFATPTR). to represent pointers implemented as capabilities. Therefore, we need to avoid using ISD::ADD for our patterns that operate on pointers and need to use a function that chooses ISD::ADD or a new ISD::PTRADD opcode depending on the value type. We originally added a new DAG.getPointerAdd() function, but after this patch series we can modify the implementation of getMemBasePlusOffset() instead. Avoiding direct uses of ISD::ADD for pointer types will significantly reduce the amount of assertion/instruction selection failures for us in future upstream merges. Reviewers: spatel, craig.topper Reviewed By: spatel, craig.topper Subscribers: craig.topper, merge_guards_bot, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71205
* [NFC] Change SelectionDAG::getMemBasePlusOffset() to use int64_tAlex Richardson2019-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is preparatory work to use this helper functions in more places. Currently the function only allows positive offsets, but there are cases where we want to subtract an offset from an existing pointer. The motivation for this change is our out-of-tree CHERI backend (https://github.com/CTSRD-CHERI/llvm-project). We use a separate register type to store pointers (128-bit capabilities, which are effectively unforgeable and monotonic fat pointers). These capabilities permit a reduced set of operations and therefore use a separate ValueType (iFATPTR). to represent pointers implemented as capabilities. Therefore, we need to avoid using ISD::ADD for our patterns that operate on pointers and need to use a function that chooses ISD::ADD or a new ISD::PTRADD opcode depending on the value type. We originally added a new DAG.getPointerAdd() function, but after this patch series we can modify the implementation of getMemBasePlusOffset() instead. Avoiding direct uses of ISD::ADD for pointer types will significantly reduce the amount of assertion/instruction selection failures for us in future upstream merges. Reviewers: spatel Reviewed By: spatel Subscribers: merge_guards_bot, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71204
* [DAGCombiner] fold shift-trunc-shift to shift-mask-trunc (2nd try)Sanjay Patel2019-12-131-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The initial attempt (rG89633320) botched the logic by reversing the source/dest types. Added x86 tests for additional coverage. The vector tests show a potential improvement (fold vector load instead of broadcasting), but that's a known/existing problem. This fold is done in IR by instcombine, and we have a special form of it already here in DAGCombiner, but we want the more general transform too: https://rise4fun.com/Alive/3jZm Name: general Pre: (C1 + zext(C2) < 64) %s = lshr i64 %x, C1 %t = trunc i64 %s to i16 %r = lshr i16 %t, C2 => %s2 = lshr i64 %x, C1 + zext(C2) %a = and i64 %s2, zext((1 << (16 - C2)) - 1) %r = trunc %a to i16 Name: special Pre: C1 == 48 %s = lshr i64 %x, C1 %t = trunc i64 %s to i16 %r = lshr i16 %t, C2 => %s2 = lshr i64 %x, C1 + zext(C2) %r = trunc %s2 to i16 ...because D58017 exposes a regression without this fold.
* Reland [DataLayout] Fix occurrences that size and range of pointers are ↵Nicola Zaghen2019-12-131-2/+2
| | | | | | | | | | | | | | assumed to be the same. GEP index size can be specified in the DataLayout, introduced in D42123. However, there were still places in which getIndexSizeInBits was used interchangeably with getPointerSizeInBits. This notably caused issues with Instcombine's visitPtrToInt; but the unit tests was incorrect, so this remained undiscovered. This fixes the buildbot failures. Differential Revision: https://reviews.llvm.org/D68328 Patch by Joseph Faulls!
* [NFC] Use EVT instead of bool for getSetCCInverse()Alex Richardson2019-12-134-19/+25
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The use of a boolean isInteger flag (generally initialized using VT.isInteger()) caused errors in our out-of-tree CHERI backend (https://github.com/CTSRD-CHERI/llvm-project). In our backend, pointers use a separate ValueType (iFATPTR) and therefore .isInteger() returns false. This meant that getSetCCInverse() was using the floating-point variant and generated incorrect code for us: `(void *)0x12033091e < (void *)0xffffffffffffffff` would return false. Committing this change will significantly reduce our merge conflicts for each upstream merge. Reviewers: spatel, bogner Reviewed By: bogner Subscribers: wuzish, arsenm, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, jrtc27, atanasyan, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70917
* Recommit "[AArch64][SVE] Implement intrinsics for non-temporal loads & stores"Kerry McLaughlin2019-12-131-1/+4
| | | | | | | | | | | | | | Updated pred_load patterns added to AArch64SVEInstrInfo.td by this patch to use reg + imm non-temporal loads to fix previous test failures. Original commit message: Adds the following intrinsics: - llvm.aarch64.sve.ldnt1 - llvm.aarch64.sve.stnt1 This patch creates masked loads and stores with the MONonTemporal flag set when used with the intrinsics above.
* [LiveDebugValues] Omit entry values for DBG_VALUEs with pre-existing expressionsDavid Stenberg2019-12-131-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a quickfix for PR44275. An assertion that checks that the DIExpression is valid failed due to attempting to create an entry value for an indirect parameter. This started appearing after D69028, as the indirect parameter started being represented using an DW_OP_deref, rather than with the DBG_VALUE's second operand, meaning that the isIndirectDebugValue() check in LiveDebugValues did not exclude such parameters. A DIExpression that has an entry value operation can currently not have any other operation, leading to the failed isValid() check. This patch simply makes us stop considering emitting entry values for such parameters. To support such cases I think we at least need to do the following changes: * In DIExpression::isValid(): Remove the limitation that a DW_OP_LLVM_entry_value operation can be the only operation in a DIExpression. * In LiveDebugValues::emitEntryValues(): Create an entry value of size 1, so that it only wraps the register operand, and not the whole pre-existing expression (the DW_OP_deref). * In LiveDebugValues::removeEntryValue(): Check that the new debug value has the same debug expression as the original, rather than checking that the debug expression is empty. * In DwarfExpression::addMachineRegExpression(): Modify the logic so that a DW_OP_reg* expression is emitted for the entry value. That is how GCC emits entry values for indirect parameters. That will currently not happen to due the DW_OP_deref causing the !HasComplexExpression to fail. The LocationKind needs to be changed also, rather than always emitting a DW_OP_stack_value for entry values. There are probably more things I have missed, but that could hopefully be a good starting point for emitting such entry values. Reviewers: djtodoro, aprantl, jmorse, vsk Reviewed By: aprantl, vsk Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D71416
* [LegalizeTypes] Remove unnecessary if before calling ReplaceValueWith on the ↵Craig Topper2019-12-131-2/+1
| | | | | | | | | | chain in SoftenFloatRes_LOAD. I believe this is a leftover from when fp128 was softened to fp128 on X86-64. In that case type legalization must have been able to create a load that was the same as N which would make this replacement fail or assert. Since we no longer do that, this check should be unneeded.
* Temporarily revert "NFC: DebugInfo: Refactor RangeSpanList to be a struct, ↵Eric Christopher2019-12-124-11/+19
| | | | | | | | like DebugLocStream::List" as it was causing bot and build failures. This reverts commit 8e04896288d22ed8bef7ac367923374f96b753d6.
* NFC: DebugInfo: Refactor RangeSpanList to be a struct, like DebugLocStream::ListDavid Blaikie2019-12-124-19/+11
| | | | | Move these data structures closer together so their emission code can eventually share more of its implementation.
* NFC: DebugInfo: Refactor debug_loc/loclist emission into a common functionDavid Blaikie2019-12-122-21/+15
| | | | | | | | | (except for v4 loclists, which are sufficiently different to not fit well in this generic implementation) In subsequent patches I intend to refactor the DebugLoc and ranges data structures to be more similar so I can common more of the implementation here.
* hwasan: add tag_offset DWARF attribute to optimized debug infoEvgenii Stepanov2019-12-125-1/+32
| | | | | | | | | | | | | | | Summary: Support alloca-referencing dbg.value in hwasan instrumentation. Update AsmPrinter to emit DW_AT_LLVM_tag_offset when location is in loclist format. Reviewers: pcc Subscribers: srhines, aprantl, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70753
* Revert "[DAGCombiner] fold shift-trunc-shift to shift-mask-trunc"Sanjay Patel2019-12-121-12/+0
| | | | | This reverts commit 8963332c3327daa652ba3e26d35f9109b6991985. There was a logic bug typo in this code, but it wasn't visible in the asm for the tests.
* [DAGCombiner] fold shift-trunc-shift to shift-mask-truncSanjay Patel2019-12-121-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fold is done in IR by instcombine, and we have a special form of it already here in DAGCombiner, but we want the more general transform too: https://rise4fun.com/Alive/3jZm Name: general Pre: (C1 + zext(C2) < 64) %s = lshr i64 %x, C1 %t = trunc i64 %s to i16 %r = lshr i16 %t, C2 => %s2 = lshr i64 %x, C1 + zext(C2) %a = and i64 %s2, zext((1 << (16 - C2)) - 1) %r = trunc %a to i16 Name: special Pre: C1 == 48 %s = lshr i64 %x, C1 %t = trunc i64 %s to i16 %r = lshr i16 %t, C2 => %s2 = lshr i64 %x, C1 + zext(C2) %r = trunc %s2 to i16 ...because D58017 exposes a regression without this fold.
* [DAGCombiner] improve readabilitySanjay Patel2019-12-121-11/+11
| | | | | | | | | | | This is not quite NFC because I changed the SDLoc to use the more standard 'N' (the starting node for the fold). This transform is a special-case of a more general fold that we do in IR, but it seems like the general fold is needed here too to avoid a potential regression seen in D58017. https://rise4fun.com/Alive/3jZm
* [DebugInfo] Prevent invalid fragments at ISel from dropping debug infostozer2019-12-121-1/+7
| | | | | | | | | | | | | During SelectionDAG, if a value which is associated with a DBG_VALUE needs to be split across multiple registers, the DBG_VALUE will be split into a set of fragment expressions to recreate the original value. If one or more of these fragments cannot be created, they would previously be silently dropped, causing the old debug value to live past its expiry date. This patch fixes this issue by keeping invalid fragments while setting their value as Undef. Differential revision: https://reviews.llvm.org/D70248
* Temporarily Revert "[DataLayout] Fix occurrences that size and range of ↵Nicola Zaghen2019-12-121-2/+2
| | | | | | | | | pointers are assumed to be the same." This reverts commit 5f6208778ff92567c57d7c1e2e740c284d7e69a5. This caused failures in Transforms/PhaseOrdering/scev-custom-dl.ll const: Assertion `getBitWidth() == CR.getBitWidth() && "ConstantRange types don't agree!"' failed.
OpenPOWER on IntegriCloud