summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstCombine] Turn (extractelement <1 x i64/double> (bitcast (x86_mmx))) ↵Craig Topper2019-11-101-0/+7
| | | | | | | | | | | | | into a single bitcast from x86_mmx to i64/double. The _m64 type is represented in IR as <1 x i64>. The x86-64 ABI on Linux passes <1 x i64> as a double. MMX intrinsics use x86_mmx type in IR.These things result in a lot of bitcasts in mmx code. There's another instcombine that tries to turn bitcast <1 x i64> to double into extractelement and a bitcast. The combine here tries to reverse this extractelement conversion if we see an mmx type.
* Revert "[InstCombine] avoid crash from deleting an instruction that still ↵Sanjay Patel2019-11-101-20/+4
| | | | | | | has uses (PR43723) (2nd try)" This reverts commit 56b2aee1875a1ee47ddf859a6584f8728787fb7b. Still causes a use-after-free on sanitizer bots.
* [InstCombine] avoid crash from deleting an instruction that still has uses ↵Sanjay Patel2019-11-101-4/+20
| | | | | | | | | | | | | | | | | | | (PR43723) (2nd try) Re-try rGef02831f0a4e (reverted due to use-after-free), but bail out completely if we encounter an unexpected llvm.invariant.start. We gather a set of white-listed instructions in isAllocSiteRemovable() and then replace/erase them. But we don't know in general if the instructions in the set have uses amongst themselves, so order of deletion makes a difference. There's already a special-case for the llvm.objectsize intrinsic, so add another for llvm.invariant.end. Should fix: https://bugs.llvm.org/show_bug.cgi?id=43723 Differential Revision: https://reviews.llvm.org/D69977
* getArgOperandNo helper function.Stefan Stipanovic2019-11-101-2/+2
| | | | | | | | | | | | Summary: A helper function to get argument number of a arg operand Use. Reviewers: jdoerfert, uenoku Subscribers: hiraditya, lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66844
* Revert "[InstCombine] avoid crash from deleting an instruction that still ↵Sanjay Patel2019-11-101-17/+4
| | | | | | | has uses (PR43723)" This reverts commit ef02831f0a4e3b3ccaa45a5589e4cabecbf527ab. Sanitizer bots fail with this change.
* [RISCV] Fix CFA when doing split sp adjustment with fpLuís Marques2019-11-101-15/+25
| | | | | | | | | | | | | Summary: When using the split sp adjustment and using the frame-pointer we were still emitting CFI CFA directives based on the sp value. The final sp-based offset also didn't reflect the two-stage sp adjust. There remain CFI issues that aren't related to the split sp adjustment, and thus will be addressed in a separate patch. Reviewers: asb, lenary, shiva0217 Reviewed By: lenary, shiva0217 Tags: #llvm Differential Revision: https://reviews.llvm.org/D69385
* [RISCV][NFC] Add CFI-related testsLuís Marques2019-11-101-0/+2
| | | | | | | | | | Summary: Adds tests necessary to properly show the impact of other patches that affect the emission of CFI directives. Reviewers: asb, lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D69721
* [InstCombine] avoid crash from deleting an instruction that still has uses ↵Sanjay Patel2019-11-101-4/+17
| | | | | | | | | | | | | | | | (PR43723) We gather a set of white-listed instructions in isAllocSiteRemovable() and then replace/erase them. But we don't know in general if the instructions in the set have uses amongst themselves, so order of deletion makes a difference. There's already a special-case for the llvm.objectsize intrinsic, so add another for llvm.invariant.end. Should fix: https://bugs.llvm.org/show_bug.cgi?id=43723 Differential Revision: https://reviews.llvm.org/D69977
* Remove unused variable (which allows us to remove vector include). NFC.Simon Pilgrim2019-11-101-3/+0
|
* TableGen - fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-102-6/+6
|
* [MC] Clean up MacroInstantiation. NFCFangrui Song2019-11-091-13/+5
|
* [NFC]: Fix PVS Studio warning in LoopNestAnalysisTsang Whitney W.H2019-11-101-3/+3
| | | | | | | | | | | | | | | | | | Summary:This patch fixes the following warnings uncovered by PVS Studio: /home/xbolva00/LLVM/llvm-project/llvm/lib/Analysis/LoopCacheAnalysis.cpp 353 warn V612 An unconditional 'return' within a loop. /home/xbolva00/LLVM/llvm-project/llvm/lib/Analysis/LoopCacheAnalysis.cpp 456 err V502 Perhaps the '?:' operator works in a different way than it was expected. The '?:' operator has a lower priority than the '==' operator. Authored By:etiotto Reviewer:Meinersbur, kbarton, bmahjour, Whitney, xbolva00 Reviewed By:xbolva00 Subscribers:hiraditya, llvm-commits Tag:LLVM Differential Revision:https://reviews.llvm.org/D69821
* [X86] Handle MO_ConstantPoolIndex in X86AsmPrinter::PrintOperandCraig Topper2019-11-091-0/+1
| | | | Fixes PR43952
* YAMLParser - fix SimpleKey uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-091-4/+4
|
* RegisterCoalescer - remove duplicate variable to fix Wshadow warning. NFCI.Simon Pilgrim2019-11-091-3/+2
|
* RegisterCoalescer - fix uninitialized variables. NFCI.Simon Pilgrim2019-11-091-10/+10
|
* [LV] Apply sink-after & interleave-groups as VPlan transformations (NFCI)Gil Rapaport2019-11-095-128/+175
| | | | | | | | | This recommits 11ed1c0239fd51fd2f064311dc7725277ed0a994 (reverted in 9f08ce0d2197d4f163dfa4633eae2347ce8fc881 for failing an assert) with a fix: tryToWidenMemory() now first checks if the widening decision is to interleave, thus maintaining previous behavior where tryToInterleaveMemory() was called first, giving priority to interleave decisions over widening/scalarization. This commit adds the test case that exposed this bug as a LIT.
* Fix shadow variable warning with llvm::SrcMgr. NFCI.Simon Pilgrim2019-11-091-2/+2
|
* Fix operator precedence warning. NFC.Simon Pilgrim2019-11-091-1/+1
|
* Fix builds where LLVM_ENABLE_STATS is disabledSimon Pilgrim2019-11-091-1/+1
| | | | Missed Stats->EnableStats rename in rG3fb832fe8bdc317687d5a4d2ca20f5f73b089341
* Remarks - fix static analyzer warnings. NFCI.Simon Pilgrim2019-11-092-8/+9
| | | | | | | - Fix uninitialized variable warnings. - Reuse BitstreamEntry iterator to avoid Wshadow warning. - Match declaration + definition arg names in BitstreamRemarkParser::processCommonMeta - Make BitstreamRemarkParser(StringRef) constructor explicit
* Remove duplicate MemVT to fix shadow variable warning. NFCI.Simon Pilgrim2019-11-091-1/+0
|
* Statistic - Fix shadow variable warning. NFCI.Simon Pilgrim2019-11-091-4/+4
| | | | Rename option 'Stats' to 'EnableStats' and prevent clash with StatisticInfo::Stats member
* Remove superfluous break after return. NFC.Simon Pilgrim2019-11-091-2/+0
|
* Fix shadow variable warning by reducing scope of CC/InverseCC CondCodes. NFCI.Simon Pilgrim2019-11-091-3/+3
|
* Remarks - fix shadow variable warnings. NFCI.Simon Pilgrim2019-11-092-14/+16
| | | | Avoid conflict with llvm::remarks::Magic global variable.
* Refactor SimplifySelectsFeedingBinaryOp for D64713. NFC.Jay Foad2019-11-091-25/+32
|
* ThinLTO : Import always_inline functions irrespective of the thresholdTeresa Johnson2019-11-089-5/+22
| | | | | | | | | | | | | | | | Summary: A user can force a function to be inlined by specifying the always_inline attribute. Currently, thinlto implementation is not aware of always_inline functions and does not guarantee import of such functions, which in turn can prevent inlining of such functions. Patch by Bharathi Seshadri <bseshadr@cisco.com> Reviewers: tejohnson Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70014
* DebugInfo: Remove redundant conditionals/checks from macro info emissionDavid Blaikie2019-11-081-18/+8
| | | | | These checks fall out naturally from the current implementation without needing to be explicitly considered anymore.
* DebugInfo: Do not create a debug_macinfo section if no CUs have associated ↵David Blaikie2019-11-081-4/+2
| | | | | | macros Patch based on Sourabh Singh's D69839 patch.
* NVPTX: Don't insert an extra empty line at the end of the last section.David Blaikie2019-11-081-2/+0
| | | | | | | This was arbitrarily appearing in only the last section emitted - which made tests more sensitive than they needed to be (removing the last section - like the macinfo section change that's coming after this) would, surprisingly, move the blank line to the previous section.
* [MC] Emit unused undefined symbol even if its binding is not setFangrui Song2019-11-081-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | Recommit r373168, which was reverted by r373242. This actually exposed a boringssl bug which has been fixed for more than one month. For the following two cases, we currently suppress the symbols. This patch emits them (compatible with GNU as). * `test2_a = undef`: if `undef` is otherwise unused. * `.hidden hidden`: if `hidden` is unused. This is the main point of the patch, because omitting the symbol would cause a linker semantic difference. It causes a behavior change that is not compatible with GNU as: .weakref foo1, bar1 When neither foo1 nor bar1 is used, we now emit bar1, which is arguably more consistent. Another change is that we will emit .TOC. for .TOC.@tocbase . For this directive, suppressing .TOC. can be seen as a size optimization, but we choose to drop it for simplicity and consistency.
* [TargetLowering][DAGCombine][MSP430] Shift Amount Threshold in DAGCombine ↵joanlluch2019-11-082-0/+15
| | | | | | | | | | | | | | | | | | | | | (3) (baseline tests) Summary: This is baseline tests for D69326 Incorporates a command line flag for the MSP430 and adds a test cases to help showing the effects of applying D69326 More details and motivation for this patch in D69326 Reviewers: spatel, asl, lebedev.ri Reviewed By: spatel, asl Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69975
* DebugInfo: Use separate macinfo contributions for each CUDavid Blaikie2019-11-082-37/+43
| | | | | | | | | | | | | | | | The macinfo support was broken for LTO situations, by terminating macinfo lists only once - multiple macinfo contributions were correctly labeled, but they all continued/flowed into later contributions until only one terminator appeared at the end of the section. Correctly terminate each contribution & fix the parsing to handle this situation too. The parsing fix is also necessary for dumping linked binaries - the previous code would stop at the end of the first contribution - missing all later contributions in a linked binary. It'd be nice to improve the dumping to print the offsets of each contribution so it'd be easier to know which CU AT_macro_info refers to which macinfo contribution.
* [DDG] Data Dependence Graph - Pi Blockbmahjour2019-11-082-11/+207
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG nodes that are part of a strongly-connected component of the graph. Replacing all the SCCs with pi-blocks results in an acyclic representation of the DDG. For example if we have: {a -> b}, {b -> c, d}, {c -> a} the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows: {p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a} In this implementation the edges between nodes that are part of the pi-block are preserved. The crossing edges (edges where one end of the edge is in the set of nodes belonging to an SCC and the other end is outside that set) are replaced with corresponding edges to/from the pi-block node instead. Authored By: bmahjour Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert Reviewed By: Meinersbur Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack Tag: #llvm Differential Revision: https://reviews.llvm.org/D68827
* [AArch64][X86] Don't assume __powidf2 is available on Windows.Eli Friedman2019-11-085-64/+52
| | | | | | | | | | We had some code for this for 32-bit ARM, but this doesn't really need to be in target-specific code; generalize it. (I think this started showing up recently because we added an optimization that converts pow to powi.) Differential Revision: https://reviews.llvm.org/D69013
* Revert "[LV] Apply sink-after & interleave-groups as VPlan transformations ↵Gil Rapaport2019-11-085-170/+125
| | | | | | (NFCI)" This reverts commit 11ed1c0239fd51fd2f064311dc7725277ed0a994 - causes an assert failure.
* Reapply [LVI] Normalize pointer behaviorNikita Popov2019-11-081-89/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix cache invalidation by not guarding the dereferenced pointer cache erasure by SeenBlocks. SeenBlocks is only populated when actually caching a value in the block, which doesn't necessarily have to happen just because dereferenced pointers were calculated. ----- Related to D69686. As noted there, LVI currently behaves differently for integer and pointer values: For integers, the block value is always valid inside the basic block, while for pointers it is only valid at the end of the basic block. I believe the integer behavior is the correct one, and CVP relies on it via its getConstantRange() uses. The reason for the special pointer behavior is that LVI checks whether a pointer is dereferenced in a given basic block and marks it as non-null in that case. Of course, this information is valid only after the dereferencing instruction, or in conservative approximation, at the end of the block. This patch changes the treatment of dereferencability: Instead of including it inside the block value, we instead treat it as something similar to an assume (it essentially is a non-nullness assume) and incorporate this information in intersectAssumeOrGuardBlockValueConstantRange() if the context instruction is the terminator of the basic block. This happens either when determining an edge-value internally in LVI, or when a terminator was explicitly passed to getValueAt(). The latter case makes this change not fully NFC, because we can now fold terminator icmps based on the dereferencability information in the same block. This is the reason why I changed one JumpThreading test (it would optimize the condition away without the change). Of course, we do not want to recompute dereferencability on each intersectAssume call, so we need a new cache for this. The dereferencability analysis requires walking the entire basic block and computing underlying objects of all memory operands. This was previously done separately for each queried pointer value. In the new implementation (both because this makes the caching simpler, and because it is faster), I instead only walk the full BB once and cache all the dereferenced pointers. So the traversal is now performed only once per BB, instead of once per queried pointer value. I think the overall model now makes more sense than before, and there will be no more pitfalls due to differing integer/pointer behavior. Differential Revision: https://reviews.llvm.org/D69914
* [clang] Add VFS support for sanitizers' blacklistsJan Korous2019-11-081-2/+2
| | | | Differential Revision: https://reviews.llvm.org/D69648
* [ThinLTO] Fix bug when importing writeonly variablesevgeny2019-11-083-8/+37
| | | | | | | | Patch enables import of write-only variables with non-trivial initializers to fix linker errors. Initializers of imported variables are converted to 'zeroinitializer' to avoid promotion of referenced objects. Differential revision: https://reviews.llvm.org/D70006
* [JumpThreading] Fix a comment typo (NFC)Kazu Hirata2019-11-081-1/+1
| | | | | | | | | | Reviewers: kazu Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70013
* Revert "[LVI] Normalize pointer behavior"Nikita Popov2019-11-081-94/+89
| | | | | | | This reverts commit 15bc4dc9a8949f9cffd46ec647baf0818d28fb28. clang-cmake-x86_64-sde-avx512-linux buildbot reported quite a few compile-time regressions in test-suite, will investigate.
* [LVI] Normalize pointer behaviorNikita Popov2019-11-081-89/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Related to D69686. As noted there, LVI currently behaves differently for integer and pointer values: For integers, the block value is always valid inside the basic block, while for pointers it is only valid at the end of the basic block. I believe the integer behavior is the correct one, and CVP relies on it via its getConstantRange() uses. The reason for the special pointer behavior is that LVI checks whether a pointer is dereferenced in a given basic block and marks it as non-null in that case. Of course, this information is valid only after the dereferencing instruction, or in conservative approximation, at the end of the block. This patch changes the treatment of dereferencability: Instead of including it inside the block value, we instead treat it as something similar to an assume (it essentially is a non-nullness assume) and incorporate this information in intersectAssumeOrGuardBlockValueConstantRange() if the context instruction is the terminator of the basic block. This happens either when determining an edge-value internally in LVI, or when a terminator was explicitly passed to getValueAt(). The latter case makes this change not fully NFC, because we can now fold terminator icmps based on the dereferencability information in the same block. This is the reason why I changed one JumpThreading test (it would optimize the condition away without the change). Of course, we do not want to recompute dereferencability on each intersectAssume call, so we need a new cache for this. The dereferencability analysis requires walking the entire basic block and computing underlying objects of all memory operands. This was previously done separately for each queried pointer value. In the new implementation (both because this makes the caching simpler, and because it is faster), I instead only walk the full BB once and cache all the dereferenced pointers. So the traversal is now performed only once per BB, instead of once per queried pointer value. I think the overall model now makes more sense than before, and there will be no more pitfalls due to differing integer/pointer behavior. Differential Revision: https://reviews.llvm.org/D69914
* TimeTraceProfiler - fix uninitialized variable warning. NFCI.Simon Pilgrim2019-11-081-3/+3
|
* [LICM] Support hosting of dynamic allocas out of loopsPhilip Reames2019-11-081-0/+45
| | | | | | | | | | | | This patch implements a correct, but not terribly useful, transform. In particular, if we have a dynamic alloca in a loop which is guaranteed to execute, and provably not captured, we hoist the alloca out of the loop. The capture tracking is needed so that we can prove that each previous stack region dies before the next one is allocated. The transform decreases the amount of stack allocation needed by a linear factor (e.g. the iteration count of the loop). Now, I really hope no one is actually using dynamic allocas. As such, why this patch? Well, the actual problem I'm hoping to make progress on is allocation hoisting. There's a large draft patch out for review (https://reviews.llvm.org/D60056), and this patch was the smallest chunk of testable functionality I could come up with which takes a step vaguely in that direction. Once this is in, it makes motivating the changes to capture tracking mentioned in TODOs testable. After that, I hope to extend this to trivial malloc free regions (i.e. free dominating all loop exits) and allocation functions for GCed languages. Differential Revision: https://reviews.llvm.org/D69227
* [LICM] Hoisting of widenable conditions out of loopsPhilip Reames2019-11-081-0/+4
| | | | | | The change itself is straight forward and obvious, but ... there's an existing test checking for exactly the opposite. Both I and Artur think this is simply conservatism in the initial implementation. If anyone bisects a problem to this, a counter example will be very interesting. Differential Revision: https://reviews.llvm.org/D69907
* [CostModel] Fixed isExtractSubvectorMask for undef index off endTim Renouf2019-11-081-1/+1
| | | | | | | | | | | | | | | | | | | ShuffleVectorInst::isExtractSubvectorMask, introduced in [CostModel] Add SK_ExtractSubvector handling to getInstructionThroughput (PR39368) erroneously thought that %340 = shufflevector <4 x float> %339, <4 x float> undef, <3 x i32> <i32 2, i32 3, i32 undef> is a subvector extract, even though it goes off the end of the parent vector with the undef index. That then caused an assert in BasicTTIImplBase::getExtractSubvectorOverhead. This commit fixes that, by not considering the above a subvector extract. Differential Revision: https://reviews.llvm.org/D70005 Change-Id: I87b8b00b24bef19ffc9a1b82ef4eca3b8a246eaf
* [PowerPC] Remove redundant CRSET/CRUNSET in custom lowering of known CR bit ↵Yi-Hong Lyu2019-11-083-3/+37
| | | | | | | | | | | | | | | | | | | | | | spills We lower known CR bit spills (CRSET/CRUNSET) to load and spill the known value but forgot to remove the redundant spills. e.g., This sequence was used to spill a CRUNSET: crclr 4*cr5+lt mfocrf r3,4 rlwinm r3,r3,20,0,0 stw r3,132(r1) Custom lowering of known CR bit spills lower it to: crxor 4*cr5+lt, 4*cr5+lt, 4*cr5+lt li r3,0 stw r3,132(r1) crxor is redundant if there is no use of 4*cr5+lt so we should remove it Differential revision: https://reviews.llvm.org/D67722
* raw_ostream - fix static analyzer warnings. NFCI.Simon Pilgrim2019-11-081-6/+6
| | | | | - uninitialized variables - make BufferKind a scoped enum class
* [NFC] ConstantRange::subWithNoWrap(): fixup commentRoman Lebedev2019-11-081-1/+1
|
OpenPOWER on IntegriCloud