summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* ARMBaseInstrInfo getOperandLatency - silence static analyzer dyn_cast<> null ↵Simon Pilgrim2019-09-261-2/+2
| | | | | | | | dereference warnings. NFCI. The static analyzer is warning about potential null dereferences, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 372992
* [PowerPC] Fix typo in rL372985Jinsong Ji2019-09-261-1/+1
| | | | llvm-svn: 372991
* [LoopInfo] Limit the iterations to check whether a loop has dedicated exitsWei Mi2019-09-261-0/+7
| | | | | | | | | | | | | | for extreme large case. We had a case that a single loop which has 4000 exits and the average number of predecessors of each exit is > 1000, and we found compiling the case spent a significant amount of time on checking whether a loop has dedicated exits. This patch adds a limit for the iterations to the check. With the patch, the time to compile our testcase reduced from 1000s to 200s (clang release build). Differential Revision: https://reviews.llvm.org/D67359 llvm-svn: 372990
* Handle successor's PHI node correctly when flattening CFG merges two if-regionsJakub Kuderski2019-09-261-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: FlattenCFG merges two 'if' basicblocks by inserting one basicblock to another basicblock. The inserted basicblock can have a successor that contains a PHI node whoes incoming basicblock is the inserted basicblock. Since the existing code does not handle it, it becomes a badref. if (cond1) statement if (cond2) statement successor - contains PHI node whose predecessor is cond2 --> if (cond1 || cond2) statement (BB for cond2 was deleted) successor - contains PHI node whose predecessor is cond2 --> bad ref! Author: Jaebaek Seo Reviewers: asbirlea, kuhar, tstellar, chandlerc, davide, dexonsmith Reviewed By: kuhar Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68032 llvm-svn: 372989
* [NFC] Rearrange Value::getPointerAlignmentGuillaume Chatelet2019-09-261-21/+23
| | | | | | | | | | | | Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67918 llvm-svn: 372987
* Updated comments in LWZtoc pseudo expansion.Sean Fertile2019-09-261-4/+5
| | | | | | | Refined a couple of the comments in the LWZtoc expansion code based on a post commit review comment. llvm-svn: 372986
* [PowerPC] Add missing pattern for VSX Scalar Negative Multiply-Subtract ↵Jinsong Ji2019-09-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Single Precision Summary: This was found during review of https://reviews.llvm.org/D66050. In the simple test of fdiv, we miss to fold ``` fneg 2, 2 xsmaddasp 3, 2, 0 ``` to ``` xsnmsubasp 3, 2, 0 ``` We have the patterns for Double Precision and vectors, just missing Single Precision, the patch add that. Reviewers: #powerpc, hfinkel, nemanjai, steven.zhang Reviewed By: #powerpc, steven.zhang Subscribers: wuzish, hiraditya, kbarton, MaskRay, shchenz, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67595 llvm-svn: 372985
* [FlattenCFG] Silence static analyzer dyn_cast<BranchInst> null dereference ↵Simon Pilgrim2019-09-261-4/+4
| | | | | | | | warnings. NFCI. The static analyzer is warning about a potential null dereferences, but we should be able to use cast<BranchInst> directly and if not assert will fire for us. llvm-svn: 372977
* [InstCombine] Don't assume CmpInst has been visited in ↵Bjorn Pettersson2019-09-261-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | getFlippedStrictnessPredicateAndConstant Summary: Removing an assumption (assert) that the CmpInst already has been simplified in getFlippedStrictnessPredicateAndConstant. Solution is to simply bail out instead of hitting the assertion. Instead we assume that any profitable rewrite will happen in the next iteration of InstCombine. The reason why we can't assume that the CmpInst already has been simplified is that the worklist does not guarantee such an ordering. Solves https://bugs.llvm.org/show_bug.cgi?id=43376 Reviewers: spatel, lebedev.ri Reviewed By: lebedev.ri Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68022 llvm-svn: 372972
* MetadataLoader lazyLoadOneMetadata - silence static analyzer ↵Simon Pilgrim2019-09-261-1/+1
| | | | | | | | dyn_cast<MDNode> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<MDNode> directly and if not assert will fire for us. llvm-svn: 372966
* Remove local shadow constant. NFCI.Simon Pilgrim2019-09-261-2/+0
| | | | | | ValueTracking.cpp already has a local static MaxDepth = 6 constant - this one seems to have been missed when rL124183 landed. llvm-svn: 372964
* [ValueTracking] Silence static analyzer dyn_cast<Operator> null dereference ↵Simon Pilgrim2019-09-261-225/+228
| | | | | | | | warnings. NFCI. The static analyzer is warning about a potential null dereferences, but since the pointer is only used in a switch statement for Operator::getOpcode() (with an empty default) then its easiest just to wrap this in a null test as the dyn_cast might return null here. llvm-svn: 372962
* MemorySanitizer - silence static analyzer dyn_cast<> null dereference ↵Simon Pilgrim2019-09-261-3/+3
| | | | | | | | warnings. NFCI. The static analyzer is warning about a potential null dereferences, but we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 372960
* PGOMemOPSizeOpt - silence static analyzer dyn_cast<MemIntrinsic> null ↵Simon Pilgrim2019-09-261-2/+2
| | | | | | | | dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<MemIntrinsic> directly and if not assert will fire for us. llvm-svn: 372959
* [BPF] Remove unused variables. NFCI.Simon Pilgrim2019-09-261-5/+1
| | | | | | Fixes a dyn_cast<> null dereference warning. llvm-svn: 372958
* [MIPS GlobalISel] Lower aggregate structure return argumentsPetar Avramovic2019-09-262-25/+42
| | | | | | | | | | | | | | Implement aggregate structure split to simpler types in splitToValueTypes. splitToValueTypes is used for return values. According to MipsABIInfo from clang/lib/CodeGen/TargetInfo.cpp, aggregate structure arguments for O32 always get simplified and thus will remain unsupported by the MIPS GlobalISel for the time being. For O32, aggregate structures can be encountered only for complex number returns e.g. 'complex float' or 'complex double' from <complex.h>. Differential Revision: https://reviews.llvm.org/D67963 llvm-svn: 372957
* HexagonAsmParser::ParseDirectiveFalign - silence static analyzer ↵Simon Pilgrim2019-09-261-1/+1
| | | | | | | | dyn_cast<MCConstantExpr> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<MCConstantExpr> directly and if not assert will fire for us. llvm-svn: 372956
* [CostModel][X86] Fix SLM <2 x i64> icmp costsSimon Pilgrim2019-09-261-0/+9
| | | | | | | | SLM is 2 x slower for <2 x i64> comparison ops than other vector types, we should account for this like we do for SLM <2 x i64> add/sub/mul costs. This should remove some of the SLM codegen diffs in D43582 llvm-svn: 372954
* [SystemZ] Recognize mnop-mcount in backendJonas Paulsson2019-09-262-0/+11
| | | | | | | | | | With -pg -mfentry -mnop-mcount, a nop is emitted instead of the call to fentry. Review: Ulrich Weigand https://reviews.llvm.org/D67765 llvm-svn: 372950
* [X86] Remove isCodeGenOnly from (V)ROUND.*_Int and put it on the non _Int ↵Craig Topper2019-09-261-6/+6
| | | | | | | | | | | | | | | | | | form instead. This matches what's done for VRNDSCALE and most other instructions. This mainly determines which instruction will be preferred by disassembler and assembly parser. The printing and encoding information is the same. We prefer the _Int form since it uses the VR128 class due to intrinsic interface. For some of EVEX features like embedded rounding, we only select from intrinsics today. So there is only a VR128 version. So making the VR128 version the preferred is overally consistent. llvm-svn: 372947
* [IfConversion] Disallow TBB == FBB for valid trianglesMikael Holmen2019-09-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously the case EBB | \_ | | | TBB | / FBB was treated as a valid triangle also when TBB and FBB was the same basic block. This could then lead to an invalid CFG when we removed the edge from EBB to TBB, since that meant we would also remove the edge from EBB to FBB. Since TBB == FBB is quite a degenerated case of a triangle, we now don't treat it as a valid triangle anymore, and thus we will avoid the trouble with updating the CFG. Reviewers: efriedma, dmgreen, kparzysz Reviewed By: efriedma Subscribers: bjope, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67832 llvm-svn: 372943
* [X86] Mark the EVEX encoded PSADBW instructions as commutable to enable load ↵Craig Topper2019-09-261-0/+1
| | | | | | | | folding of the other operand. The SSE and VEX versions are already correct. llvm-svn: 372941
* [ConstantFolding] Use FoldBitCast correctlyKeno Fischer2019-09-261-2/+20
| | | | | | | | | | | | | Previously we might attempt to use a BitCast to turn bits into vectors of pointers, but that requires an inttoptr cast to be legal. Add an assertion to detect the formation of illegal bitcast attempts early (in the tests, we often constant-fold away the result before getting to this assertion check), while being careful to still handle the early-return conditions without adding extra complexity in the result. Patch by Jameson Nash <jameson@juliacomputing.com>. Differential Revision: https://reviews.llvm.org/D65057 llvm-svn: 372940
* Improve C API support for atomicrmw and cmpxchg.Nick Lewycky2019-09-261-17/+71
| | | | | | | | | | | | | | atomicrmw and cmpxchg have a volatile flag, so allow them to be get and set with LLVM{Get,Set}Volatile. atomicrmw and fence have orderings, so allow them to be get and set with LLVM{Get,Set}Ordering. Add missing LLVMAtomicRMWBinOpFAdd and LLVMAtomicRMWBinOpFSub enum constants. AtomicCmpXchg also has a weak flag, add a getter/setter for that too. Add a getter/setter for the binary-op of an atomicrmw. atomicrmw and cmpxchg have a volatile flag, so allow it to be set/get with LLVMGetVolatile and LLVMSetVolatile. Add missing LLVMAtomicRMWBinOpFAdd and LLVMAtomicRMWBinOpFSub enum constants. AtomicCmpXchg also has a weak flag, add a getter/setter for that too. Add a getter/setter for the binary-op of an atomicrmw. Add LLVMIsA## for CatchSwitchInst, CallBrInst and FenceInst, as well as AtomicCmpXchgInst and AtomicRMWInst. Update llvm-c-test to include atomicrmw and fence, and to copy volatile for the four applicable instructions. Differential Revision: https://reviews.llvm.org/D67132 llvm-svn: 372938
* [TargetLowering] Make allowsMemoryAccess methode virtual.Thomas Raoux2019-09-268-31/+47
| | | | | | | | | | | Rename old function to explicitly show that it cares only about alignment. The new allowsMemoryAccess call the function related to alignment by default and can be overridden by target to inform whether the memory access is legal or not. Differential Revision: https://reviews.llvm.org/D67121 llvm-svn: 372935
* [MC][WebAssembly] Error on data symbols in the text section.Sam Clegg2019-09-251-1/+3
| | | | | | | | | Previously we had an assert but this can actually occur in valid user code so we need to handle this in release builds too. Differential Revision: https://reviews.llvm.org/D67997 llvm-svn: 372934
* [X86] Use VR512_0_15RegClass intead of VR512RegClass in X86VZeroUpper.Craig Topper2019-09-251-4/+2
| | | | | | | | | | | | | | This pass is only concerned with ZMM0-15 and YMM0-15. For YMM we use VR256 which only contains YMM0-15, but for ZMM we were using VR512 which contains ZMM0-31. Using VR512_0_15 is more correct. Given that the ABI and register allocator will use registers in order, its unlikely that register from 16-31 would be used without also using 0-15. So this probably doesn't functionally matter. llvm-svn: 372933
* [MemorySSA] Avoid adding Phis in the presence of unreachable blocks.Alina Sbirlea2019-09-251-45/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a block has all incoming values with the same MemoryAccess (ignoring incoming values from unreachable blocks), then use that incoming MemoryAccess and do not create a Phi in the first place. Revert IDF work-around added in rL372673; it should not be required unless the Def inserted is the first in its block. The patch also cleans up a series of tests, added during the many iterations on insertDef. The patch also fixes PR43438. The same issue that occurs in insertDef with "adding phis, hence the IDF of Phis is needed", can also occur in fixupDefs: the `getPreviousRecursive` call only adds Phis walking on the predecessor edges, which means there may be the case of a Phi added walking the CFG "backwards" which triggers the needs for an additional Phi in successor blocks. Such Phis are added during fixupDefs only in the presence of unreachable blocks. Hence this highlights the need to avoid adding Phis in blocks with unreachable predecessors in the first place. Reviewers: george.burgess.iv Subscribers: Prazek, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67995 llvm-svn: 372932
* [InstCombine] foldUnsignedUnderflowCheck(): one last pattern with 'sub' ↵Roman Lebedev2019-09-251-0/+10
| | | | | | | | (PR43251) https://rise4fun.com/Alive/0j9 llvm-svn: 372930
* [InstSimplify] Handle more 'A </>/>=/<= B &&/|| (A - B) !=/== 0' patterns ↵Roman Lebedev2019-09-251-0/+12
| | | | | | | | | | | (PR43251) https://rise4fun.com/Alive/sl9s https://rise4fun.com/Alive/2plN https://bugs.llvm.org/show_bug.cgi?id=43251 llvm-svn: 372928
* [LICM] Don't verify domtree/loopinfo unless EXPENSIVE_CHECKS is enabled.Eli Friedman2019-09-251-1/+1
| | | | | | | | | For large functions, verifying the whole function after each loop takes non-linear time. Differential Revision: https://reviews.llvm.org/D67571 llvm-svn: 372924
* [Verifier] add invariant check for callbrNick Desaulniers2019-09-251-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The list of indirect labels should ALWAYS have their blockaddresses as argument operands to the callbr (but not necessarily the other way around). Add an invariant that checks this. The verifier catches a bad test case that was added recently in r368478. I think that was a simple mistake, and the test was made less strict in regards to the precise addresses (as those weren't specifically the point of the test). This invariant will be used to find a reported bug. Link: https://www.spinics.net/lists/arm-kernel/msg753473.html Link: https://github.com/ClangBuiltLinux/linux/issues/649 Reviewers: craig.topper, void, chandlerc Reviewed By: void Subscribers: ychen, lebedev.ri, javed.absar, kristof.beyls, hiraditya, llvm-commits, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D67196 llvm-svn: 372923
* [InstSimplify] Match 1.0 and 0.0 for both operands in SimplifyFMAMulFlorian Hahn2019-09-251-0/+8
| | | | | | | | | | | | | | | | | | Because we do not constant fold multiplications in SimplifyFMAMul, we match 1.0 and 0.0 for both operands, as multiplying by them is guaranteed to produce an exact result (if it is allowed to do so). Note that it is not enough to just swap the operands to ensure a constant is on the RHS, as we want to also cover the case with 2 constants. Reviewers: lebedev.ri, spatel, reames, scanon Reviewed By: lebedev.ri, reames Differential Revision: https://reviews.llvm.org/D67553 llvm-svn: 372915
* [InstCombine] Fold (A - B) u>=/u< A --> B u>/u<= A iff B != 0Roman Lebedev2019-09-253-20/+14
| | | | | | | | | | | | | https://rise4fun.com/Alive/KtL This also shows that the fold added in D67412 / r372257 was too specific, and the new fold allows those test cases to be handled more generically, therefore i delete now-dead code. This is yet again motivated by D67122 "[UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour" llvm-svn: 372912
* [MSP430] Allow msp430_intrcc functions to not have interrupt attribute.Vadzim Dambrouski2019-09-251-3/+5
| | | | | | | | | | | | | | | | | | Summary: Useful in case you want to have control over interrupt vector generation. For example in Rust language we have an arrangement where all unhandled ISR vectors gets mapped to a single default handler function. Which is hard to implement when LLVM tries to generate vectors on its own. Reviewers: asl, krisb Subscribers: hiraditya, JDevlieghere, awygle, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67313 llvm-svn: 372910
* [AMDGPU] gfx10 v_fmac_f16 operand foldingStanislav Mekhanoshin2019-09-251-8/+15
| | | | | | | | Fold immediates into v_fmac_f16. Differential Revision: https://reviews.llvm.org/D68037 llvm-svn: 372906
* [InstCombine] Limit FMul constant folding for fma simplifications.Florian Hahn2019-09-252-12/+35
| | | | | | | | | | | | | | | | | As @reames pointed out post-commit, rL371518 adds additional rounding in some cases, when doing constant folding of the multiplication. This breaks a guarantee llvm.fma makes and must be avoided. This patch reapplies rL371518, but splits off the simplifications not requiring rounding from SimplifFMulInst as SimplifyFMAFMul. Reviewers: spatel, lebedev.ri, reames, scanon Reviewed By: reames Differential Revision: https://reviews.llvm.org/D67434 llvm-svn: 372899
* [AArch64][GlobalISel] Choose CCAssignFns per-argument for tail call loweringJessica Paquette2019-09-252-23/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | When checking for tail call eligibility, we should use the correct CCAssignFn for each argument, rather than just checking if the caller/callee is varargs or not. This is important for tail call lowering with varargs. If we don't check it, then basically any varargs callee with parameters cannot be tail called on Darwin, for one thing. If the parameters are all guaranteed to be in registers, this should be entirely safe. On top of that, not checking for this could potentially make it so that we have the wrong stack offsets when checking for tail call eligibility. Also refactor some of the stuff for CCAssignFnForCall and pull it out into a helper function. Update call-translator-tail-call.ll to show that we can now correctly tail call on Darwin. Also add two extra tail call checks. The first verifies that we still respect the caller's stack size, and the second verifies that we still don't tail call when a varargs function has a memory argument. Differential Revision: https://reviews.llvm.org/D67939 llvm-svn: 372897
* [CodeGen] Replace -max-jump-table-size with -max-jump-table-targetsEvandro Menezes2019-09-255-61/+66
| | | | | | | | | | | | | | | | | | | | | | | Modern processors predict the targets of an indirect branch regardless of the size of any jump table used to glean its target address. Moreover, branch predictors typically use resources limited by the number of actual targets that occur at run time. This patch changes the semantics of the option `-max-jump-table-size` to limit the number of different targets instead of the number of entries in a jump table. Thus, it is now renamed to `-max-jump-table-targets`. Before, when `-max-jump-table-size` was specified, it could happen that cluster jump tables could have targets used repeatedly, but each one was counted and typically resulted in tables with the same number of entries. With this patch, when specifying `-max-jump-table-targets`, tables may have different lengths, since the number of unique targets is counted towards the limit, but the number of unique targets in tables is the same, but for the last one containing the balance of targets. Differential revision: https://reviews.llvm.org/D60295 llvm-svn: 372893
* [DAGCombiner] add one-use restriction to vector transform with cheap extractSanjay Patel2019-09-251-1/+1
| | | | | | | | | | We might be able to do better on the example in the test, but in general, we should not scalarize a splatted vector binop if there are other uses of the binop. Otherwise, we can end up with code as we had - a scalar op that is redundant with a vector op. llvm-svn: 372886
* [PatternMatch] Make m_Br more flexible, add matchers for BB values.Florian Hahn2019-09-253-12/+8
| | | | | | | | | | | | | | | | | | | | | Currently m_Br only takes references to BasicBlock*, which limits its flexibility. For example, you have to declare a variable, even if you ignore the result or you have to have additional checks to make sure the matched BB matches an expected one. This patch adds m_BasicBlock and m_SpecificBB matchers, which can be used like the existing matchers for constants or values. I also had a look at the existing uses and updated a few. IMO it makes the code a bit more explicit. Reviewers: spatel, craig.topper, RKSimon, majnemer, lebedev.ri Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D68013 llvm-svn: 372885
* [TargetInstrInfo] Let findCommutedOpIndices take const MachineInstr&Simon Pilgrim2019-09-259-9/+13
| | | | | | | | | | Neither the base implementation of findCommutedOpIndices nor any in-tree target modifies the instruction passed in and there is no reason why they would in the future. Committed on behalf of @hvdijk (Harald van Dijk) Differential Revision: https://reviews.llvm.org/D66138 llvm-svn: 372882
* [IR] allow fast-math-flags on phi of FP values (2nd try)Sanjay Patel2019-09-254-8/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The changes here are based on the corresponding diffs for allowing FMF on 'select': D61917 <https://reviews.llvm.org/D61917> As discussed there, we want to have fast-math-flags be a property of an FP value because the alternative (having them on things like fcmp) leads to logical inconsistency such as: https://bugs.llvm.org/show_bug.cgi?id=38086 The earlier patch for select made almost no practical difference because most unoptimized conditional code begins life as a phi (based on what I see in clang). Similarly, I don't expect this patch to do much on its own either because SimplifyCFG promptly drops the flags when converting to select on a minimal example like: https://bugs.llvm.org/show_bug.cgi?id=39535 But once we have this plumbing in place, we should be able to wire up the FMF propagation and start solving cases like that. The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a regression in a LoopVectorize test. We are intersecting the FMF of any FPMathOperator there, so if a phi is not properly annotated, new math instructions may not be either. Once we fix the propagation in SimplifyCFG, it may be safe to remove that hack. Differential Revision: https://reviews.llvm.org/D67564 llvm-svn: 372878
* Fix analyzer TypeAttributeImpl::anchor() override.Simon Pilgrim2019-09-251-1/+1
| | | | | | TypeAttributeImpl inherits from EnumAttributeImpl which already defines anchor() as a virtual, so we should override this instead of redeclaring it. llvm-svn: 372877
* [Dominators][AMDGPU] Don't use virtual exit node in ↵Jakub Kuderski2019-09-252-26/+38
| | | | | | | | | | | | | | | | | | | | | | | findNearestCommonDominator. Cleanup MachinePostDominators. Summary: This patch fixes a bug that originated from passing a virtual exit block (nullptr) to `MachinePostDominatorTee::findNearestCommonDominator` and resulted in assertion failures inside its callee. It also applies a small cleanup to the class. The patch introduces a new function in PDT that given a list of `MachineBasicBlock`s finds their NCD. The new overload of `findNearestCommonDominator` handles virtual root correctly. Note that similar handling of virtual root nodes is not necessary in (forward) `DominatorTree`s, as right now they don't use virtual roots. Reviewers: tstellar, tpr, nhaehnle, arsenm, NutshellySima, grosser, hliao Reviewed By: hliao Subscribers: hliao, kzhuravl, jvesely, wdng, yaxunl, dstuttard, t-tye, hiraditya, llvm-commits Tags: #amdgpu, #llvm Differential Revision: https://reviews.llvm.org/D67974 llvm-svn: 372874
* [SystemZ] Improve emitSelect()Jonas Paulsson2019-09-251-33/+58
| | | | | | | | | | | | | Merge more Select pseudo instructions in emitSelect() by allowing other instructions between them as long as they do not clobber CC. Debug value instructions are now moved down to below the new PHIs instead of erasing them. Review: Ulrich Weigand https://reviews.llvm.org/D67619 llvm-svn: 372873
* Fix cppcheck variable shadow warning. NFCI.Simon Pilgrim2019-09-251-3/+3
| | | | llvm-svn: 372872
* Add missing ExplicitTy default initialization to ConstantExprKeyType ↵Simon Pilgrim2019-09-251-2/+4
| | | | | | | | constructors. Fixes cppcheck uninitialized variable warnings llvm-svn: 372871
* Revert [IR] allow fast-math-flags on phi of FP valuesSanjay Patel2019-09-255-44/+9
| | | | | | This reverts r372866 (git commit dec03223a97af0e4dfcb23da55c0f7f8c9b62d00) llvm-svn: 372868
* [IR] allow fast-math-flags on phi of FP valuesSanjay Patel2019-09-255-9/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The changes here are based on the corresponding diffs for allowing FMF on 'select': D61917 As discussed there, we want to have fast-math-flags be a property of an FP value because the alternative (having them on things like fcmp) leads to logical inconsistency such as: https://bugs.llvm.org/show_bug.cgi?id=38086 The earlier patch for select made almost no practical difference because most unoptimized conditional code begins life as a phi (based on what I see in clang). Similarly, I don't expect this patch to do much on its own either because SimplifyCFG promptly drops the flags when converting to select on a minimal example like: https://bugs.llvm.org/show_bug.cgi?id=39535 But once we have this plumbing in place, we should be able to wire up the FMF propagation and start solving cases like that. The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a regression in a LoopVectorize test. We are intersecting the FMF of any FPMathOperator there, so if a phi is not properly annotated, new math instructions may not be either. Once we fix the propagation in SimplifyCFG, it may be safe to remove that hack. Differential Revision: https://reviews.llvm.org/D67564 llvm-svn: 372866
OpenPOWER on IntegriCloud