summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/ARM
Commit message (Collapse)AuthorAgeFilesLines
* [ARM] Add new system registers to ARMv8-M Baseline/MainlineBradley Smith2016-01-152-0/+356
| | | | llvm-svn: 257884
* [ARM] Add ARMv8-A semaphore/atomic instructions to ARMv8-M Baseline/MainlineBradley Smith2016-01-151-0/+2
| | | | llvm-svn: 257882
* [ARM] Add B.W and CBZ instructions to ARMv8-M BaselineBradley Smith2016-01-151-0/+1
| | | | llvm-svn: 257881
* [ARM] Add MOVW/MOVT instructions to ARMv8-M Baseline/MainlineBradley Smith2016-01-151-2/+4
| | | | llvm-svn: 257879
* [ARM] Add ARMv8-M Baseline/Mainline LLVM targetingBradley Smith2016-01-151-0/+19
| | | | llvm-svn: 257878
* Reapply r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-151-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I originally reapplied this in 257550, but had to revert again due to bot breakage. The only change in this version is to allow either the TypeSize or the TypeAllocSize of the variable to be the one represented in debug info (hopefully in the future we can figure out how to encode the difference). Additionally, several bot failures following r257550, were due to optimizer bugs now fixed in r257787 and r257795. r257550 commit message was: ``` The follow extra changes were made to test cases: Manually making the variable be the actual type instead of a pointer to avoid pointer-size differences in generic code: LLVM :: DebugInfo/Generic/2010-03-24-MemberFn.ll LLVM :: DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll LLVM :: DebugInfo/Generic/2010-05-03-DisableFramePtr.ll LLVM :: DebugInfo/Generic/varargs.ll Delete sizing information from debug info for the same reason (but the presence of the pointer was important to the test case): LLVM :: DebugInfo/Generic/restrict.ll LLVM :: DebugInfo/Generic/tu-composite.ll LLVM :: Linker/type-unique-type-array-a.ll LLVM :: Linker/type-unique-simple2.ll Fixing an incorrect DW_OP_deref LLVM :: DebugInfo/Generic/2010-05-03-OriginDIE.ll Fixing a missing DW_OP_deref LLVM :: DebugInfo/Generic/incorrect-variable-debugloc.ll Additionally, clang should no longer complain during bootstrap should no longer happen after r257534. The original commit message was: `` Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref `` ``` llvm-svn: 257850
* [CodeGen] Don't assume fp_to_fp16 produces i16 when legalizing it.Ahmed Bougacha2016-01-141-2/+11
| | | | | | | | | | | | | | Since r230276, we support an improved legalization for f64->f16, which goes through a temporary f32, improving codegen when f32->f16 is legal but not f64->f16. This requires unsafe-fp-math. However, that legalization assumed that the second step, producing a pseudo-softened f16, had type i16. That's not true on targets with illegal i16, such as ARM. Use the initial f64->f16 result type instead. llvm-svn: 257794
* Revert "Stop increasing alignment of externally-visible globals on ELF ↵James Y Knight2016-01-141-9/+9
| | | | | | | | platforms." This reverts commit r257719, due to PR26144. llvm-svn: 257775
* Stop increasing alignment of externally-visible globals on ELFJames Y Knight2016-01-131-9/+9
| | | | | | | | | | | | | | platforms. With ELF, the alignment of a global variable in a shared library will get copied into an executables linked against it, if the executable even accesss the variable. So, it's not possible to implicitly increase alignment based on access patterns, or you'll break existing binaries. This happened to affect libc++'s std::cout symbol, for example. See thread: http://thread.gmane.org/gmane.comp.compilers.clang.devel/45311 llvm-svn: 257719
* [TLS] New lower emutls pass, fix linkage bugs.Chih-Hung Hsieh2016-01-132-21/+37
| | | | | | | | | | | | | | | | | | | Previous implementation in http://reviews.llvm.org/D10522 created external references to __emutls_v.* variables. Such references are inaccurate and cannot be handled by all linkers, e.g. Android dynamic and gold linkers for aarch64. Now a new LowerEmuTLS pass to go through all global variables, and add emutls_v.* and emutls_t.* variables. These __emutls* variables have the same linkage and visibility as the associated user defined TLS variable. Also removed old code that dump __emutls* variables in AsmPrinter.cpp, and updated TLS unit tests. Differential Revision: http://reviews.llvm.org/D15300 llvm-svn: 257718
* Re-Revert r257105 (Verifier debug info changes)Keno Fischer2016-01-131-7/+4
| | | | | | | While I investigate some new buildbot failures. This was originally reapplied as r257550 and r257558. llvm-svn: 257563
* Reapply r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-131-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The follow extra changes were made to test cases: Manually making the variable be the actual type instead of a pointer to avoid pointer-size differences in generic code: LLVM :: DebugInfo/Generic/2010-03-24-MemberFn.ll LLVM :: DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll LLVM :: DebugInfo/Generic/2010-05-03-DisableFramePtr.ll LLVM :: DebugInfo/Generic/varargs.ll Delete sizing information from debug info for the same reason (but the presence of the pointer was important to the test case): LLVM :: DebugInfo/Generic/restrict.ll LLVM :: DebugInfo/Generic/tu-composite.ll LLVM :: Linker/type-unique-type-array-a.ll LLVM :: Linker/type-unique-simple2.ll Fixing an incorrect DW_OP_deref LLVM :: DebugInfo/Generic/2010-05-03-OriginDIE.ll Fixing a missing DW_OP_deref LLVM :: DebugInfo/Generic/incorrect-variable-debugloc.ll Additionally, clang should no longer complain during bootstrap should no longer happen after r257534. The original commit message was: ``` Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref ``` llvm-svn: 257550
* Guard fabs to bfc convert with V6T2 flagAna Pazos2016-01-131-0/+14
| | | | | | | | | | | | | | Summary: BFC instructions are available in ARMv6T2 and above. Reviewers: t.p.northover Subscribers: aemerson Differential Revision: http://reviews.llvm.org/D16076 llvm-svn: 257546
* [ARM] Mark VMOV with immediate: isAsCheapAsMove.Quentin Colombet2016-01-131-37/+21
| | | | | | | | | | VMOVs are not strictly speaking cheap, but they are as expensive as a vector copy (VORR), so we should prefer rematerialization over splitting when it applies. rdar://problem/23754176 llvm-svn: 257545
* CXX_FAST_TLS calling convention: performance improvement for ARM.Manman Ren2016-01-121-8/+10
| | | | | | | This is the same change on ARM as r255821 on AArch64. rdar://9001553 llvm-svn: 257424
* CXX_FAST_TLS calling convention: Add support for ARM on Darwin.Manman Ren2016-01-111-0/+44
| | | | | | rdar://9001553 llvm-svn: 257417
* RBIT Instruction only available for ARMv6t2 and above.Weiming Zhao2016-01-081-0/+34
| | | | | | | | | | | | | | | | | Summary: r255334 matches bit-reverse pattern in InstCombine and generates calls to Instrinsic::bitreverse. RBIT instruction is only available for ARMv6t2 and above. This patch has the intrinsic expanded during legalization for ARMv4 and ARMv5. Patch by Z. Zheng <zhaoshiz@codeaurora.org> Reviewers: apazos, jmolloy, weimingz Subscribers: aemerson, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D15932 llvm-svn: 257188
* Do not ASSERTZEXT for i16 result of bitcast from f16 operandPirama Arumuga Nainar2016-01-082-3/+32
| | | | | | | | | | | | | | | | | | | | | | | Summary: During legalization if i16, do not ASSERTZEXT the result of FP_TO_FP16. Directly return an FP_TO_FP16 node with return type as the promote-to-type of i16. This patch also removes extraneous length check. This legalization should be valid even if integer and float types are of different lengths. This patch breaks a hard-float test for fp16 args. The test is changed to allow a vmov to zero-out the top bits, and also ensure that the return value is in an FP register. Reviewers: ab, jmolloy Subscribers: srhines, llvm-commits Differential Revision: http://reviews.llvm.org/D15438 llvm-svn: 257184
* Add some testing for thumb1 and thumb2 inline asm immediate constraintsEric Christopher2016-01-082-0/+51
| | | | | | | | and fix a couple of bugs on inspection. Also fixes PR26061. llvm-svn: 257122
* Temporarily revert r257105 "[Verifier] Check that debug values have proper size"Keno Fischer2016-01-071-7/+4
| | | | | | | Looks like there's a case where clang generates debug info that triggers the new verifier check. Reverting while investigating. llvm-svn: 257107
* [Verifier] Check that debug values have proper sizeKeno Fischer2016-01-071-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Teach the Verifier to make sure that the storage size given to llvm.dbg.declare or the value size given to llvm.dbg.value agree with what is declared in DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA). Additionally this catches a number of common mistakes, such as passing a pointer when a value was intended or vice versa. One complication comes from stack coloring which modifies the original IR when it merges allocas in order to make sure that if AA falls back to the IR it gets the correct result. However, given this new invariant, indiscriminately replacing one alloca by a different (differently sized one) is no longer valid. Fix this by just undefing out any use of the alloca in a dbg.declare in this case. Additionally, I had to fix a number of test cases. Of particular note: - I regenerated dbg-changes-codegen-branch-folding.ll from the given source as it was affected by the bug fixed in r256077 - two-cus-from-same-file.ll was changed to avoid having a variable-typed debug variable as that would depend on the target, even though this test is supposed to be generic - I had to manually declared size/align for reference type. See also the discussion for D14275/r253186. - fpstack-debuginstr-kill.ll required changing `double` to `long double` - most others were just a question of adding OP_deref Reviewers: aprantl Differential Revision: http://reviews.llvm.org/D14276 llvm-svn: 257105
* ARM: support TLS accesses on Darwin platformsTim Northover2016-01-071-0/+165
| | | | | | | | Darwin TLS accesses most closely resemble ELF's general-dynamic situation, since they have to be able to handle all possible situations. The descriptors and so on are obviously slightly different though. llvm-svn: 257039
* [AArch64] Add support for Samsung Exynos-M1MinSeong Kim2016-01-051-0/+36
| | | | | | | | Adds core tuning support for new Samsung Exynos-M1 core (ARMv8-A). Differential Revision: http://reviews.llvm.org/D15663 llvm-svn: 256828
* Fix several accidental DOS line endings in source filesDimitry Andric2016-01-031-17/+17
| | | | | | | | | | | | | | | Summary: There are a number of files in the tree which have been accidentally checked in with DOS line endings. Convert these to native line endings. There are also a few files which have DOS line endings on purpose, and I have set the svn:eol-style property to 'CRLF' on those. Reviewers: joerg, aaron.ballman Subscribers: aaron.ballman, sanjoy, dsanders, llvm-commits Differential Revision: http://reviews.llvm.org/D15848 llvm-svn: 256707
* Convert the CodeGen/ARM/sched-it-debug-nodes.ll testcase from IR -> MIR.Adrian Prantl2015-12-211-88/+0
| | | | | | | NFC PR24563 llvm-svn: 256187
* Fix mapping of @llvm.arm.ssat/usat intrinsics to ssat/usat instructions for ↵Weiming Zhao2015-12-205-11/+18
| | | | | | | | | | | | | | | | | Thumb2 Summary: r250697 fixed the mapping for ARM mode. We have to do the same for Thumb2 otherwise the same llvm.arm.ssat() will generate different saturating amount for ARM and Thumb. r250697: http://reviews.llvm.org/rL250697 Reviewers: rmaprath Subscribers: aemerson, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D15653 llvm-svn: 256115
* Hopefully fix debug-info-blocks.ll test on win32 botKeno Fischer2015-12-191-1/+1
| | | | | | | | llc_dwarf adds an mtriple, which forces this to use COFF, causing the test to fail. Hopefully using regular llc without the triple will work fine everywhere llvm-svn: 256084
* Clean up the processing of dbg.value in various placesKeno Fischer2015-12-191-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: First up is instcombine, where in the dbg.declare -> dbg.value conversion, the llvm.dbg.value needs to be called on the actual loaded value, rather than the address (since the whole point of this transformation is to be able to get rid of the alloca). Further, now that that's cleaned up, we can remove a hack in the backend, that would add an implicit OP_deref if the argument to dbg.value was an alloca. This stems from before the existence of DIExpression and is no longer necessary since the deref can be expressed explicitly. Now, in order to make sure that the tests pass with this change, we need to correct the printing of DEBUG_VALUE comments to take into account the expression, which wasn't taken into account before. Unfortunately, for both these changes, there were a number of incorrect test cases (mostly the wrong number of DW_OP_derefs, but also a couple where the test itself was broken more badly). aprantl and I have gone through and adjusted these test case in order to make them pass with these fixes and in some cases to make sure they're actually testing what they are meant to test. Reviewers: aprantl Subscribers: dsanders Differential Revision: http://reviews.llvm.org/D14186 llvm-svn: 256077
* Fix PR25838.Cong Hou2015-12-171-0/+34
| | | | | | | | | | This is a quick fix to PR25838. The issue comes from the restriction that we cannot normalize probabilities containing both known and unknown ones. A patch that removes this restriction is under the review now: http://reviews.llvm.org/D15548 llvm-svn: 255867
* Improve the successor list update in TailDuplication.cpp.Cong Hou2015-12-151-1/+1
| | | | | | | This patch improves a temporary fix in r255530 so that we can normalize successor list without trigger assertion failures in tail duplication pass. llvm-svn: 255638
* [ShrinkWrapping] Do not choose restore point inside loops.Quentin Colombet2015-12-151-0/+142
| | | | | | | | | | | | | | | | | | | | The post-dominance property is not sufficient to guarantee that a restore point inside a loop is safe. E.g., while(1) { Save Restore if (...) break; use/def CSRs } All the uses/defs of CSRs are dominated by Save and post-dominated by Restore. However, the CSRs uses are still reachable after Restore and before Save are executed. This fixes PR25824 llvm-svn: 255613
* ARM: only emit EABI attributes on EABI targetsSaleem Abdulrasool2015-12-131-0/+10
| | | | | | | EABI attributes should only be emitted on EABI targets. This prevents the emission of the optimization goals EABI attribute on Windows ARM. llvm-svn: 255448
* ARM: don't use a deleted node as the BaseReg in complex pattern.Tim Northover2015-12-091-0/+15
| | | | | | | | | | We mutated the DAG, which invalidated the node we were trying to use as a base register. Sometimes we got away with it, but other times the node really did get deleted before it was finished with. Should fix PR25733 llvm-svn: 255120
* [AArch64][ARM] Don't base interleaved op legality on type alloc size.Ahmed Bougacha2015-12-091-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise, we think that most types that look like they'd fit in a legal vector type are legal (so, basically, *any* vector type with a size between 33 and 128 bits, I think, since we use pow2 alignment; e.g., v2i25, v3f32, ...). DataLayout::getTypeAllocSize rounds up based on alignment. When checking for target intrinsic legality, that's not what we want: if rounding makes a difference, the type isn't legal, and the target intrinsics shouldn't be used, as they are always assumed legal. One could make the argument that alloc size is ultimately the most relevant here, since we're dealing with LD/ST intrinsics. That's only true if we did legalize them though; that's a problem for another day. Use DataLayout::getTypeSizeInBits instead of getTypeAllocSizeInBits. Type::getSizeInBits can't be used because that'd gratuitously break pointer vector support. Some of these uses are currently fine, because we only hit them when the type is already known legal (e.g., r114454). Update them for consistency. It's faster to avoid the rounding anyway! llvm-svn: 255089
* Fix ARMv4T (Thumb1) epilogue generationArtyom Skrobov2015-12-081-2/+2
| | | | | | | | | | | | | | Summary: Before ARMv5T, Thumb1 code could not pop PC, as described at D14357 and D14986; so we need the special fixup in the epilogue. Reviewers: jroelofs, qcolombet Subscribers: aemerson, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D15126 llvm-svn: 255047
* AsmPrinter: Use emitGlobalConstantFP to emit elements of constant dataJustin Bogner2015-12-081-3/+3
| | | | | | | | | | It's strange to duplicate the logic for emitting FP values into emitGlobalConstantDataSequential, and it's even stranger that we end up printing the verbose assembly comments differently between the two paths. Just call into emitGlobalConstantFP rather than crudely duplicating its logic. llvm-svn: 254988
* [ARM] Generate ABI_optimization_goals build attribute, as described in the ↵Artyom Skrobov2015-12-075-0/+100
| | | | | | | | | | | | | | ARM ARM. Summary: This reverts r254234, and adds a simple fix for the annoying case of use-after-free. Reviewers: rengolin Subscribers: aemerson, llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D15236 llvm-svn: 254912
* [ARM] Flag vcvt{t,b} with an f16 type specifier as part of the FP16 extensionBradley Smith2015-12-071-1/+1
| | | | | | Additionally correct the Cortex-R7 definition to allow the FP16 feature. llvm-svn: 254900
* [ARM] When a bitcast is about to be turned into a VMOVDRR, try to combine itQuentin Colombet2015-12-041-0/+72
| | | | | | | | | | | with its source instead of forcing the values on GPRs. This improves the lowering of vector code when such bitcasts happen in the middle of vector computations. rdar://problem/23691584 llvm-svn: 254684
* AArch64: use ldxp/stxp pair to implement 128-bit atomic loads.Tim Northover2015-12-021-0/+6
| | | | | | | | The ARM ARM is clear that 128-bit loads are only guaranteed to have been atomic if there has been a corresponding successful stxp. It's less clear for AArch32, so I'm leaving that alone for now. llvm-svn: 254524
* [AArch64]: Add support for Cortex-A35Christof Douma2015-12-021-0/+35
| | | | | | Adds support for the new Cortex-A35 ARMv8-A core. llvm-svn: 254503
* Replace all weight-based interfaces in MBB with probability-based ↵Cong Hou2015-12-015-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interfaces, and update all uses of old interfaces. (This is the second attempt to submit this patch. The first caused two assertion failures and was reverted. See https://llvm.org/bugs/show_bug.cgi?id=25687) The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes (http://reviews.llvm.org/D13908). 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights (http://reviews.llvm.org/D14361). 3. Use new interfaces in all other passes. 4. Remove old interfaces. This patch is 3+4 above. In this patch, MBB won't provide weight-based interfaces any more, which are totally replaced by probability-based ones. The interface addSuccessor() is redesigned so that the default probability is unknown. We allow unknown probabilities but don't allow using it together with known probabilities in successor list. That is to say, we either have a list of successors with all known probabilities, or all unknown probabilities. In the latter case, we assume each successor has 1/N probability where N is the number of successors. An assertion checks if the user is attempting to add a successor with the disallowed mixed use as stated above. This can help us catch many misuses. All uses of weight-based interfaces are now updated to use probability-based ones. Differential revision: http://reviews.llvm.org/D14973 llvm-svn: 254377
* Revert r254348: "Replace all weight-based interfaces in MBB with ↵Hans Wennborg2015-12-015-16/+16
| | | | | | | | | | probability-based interfaces, and update all uses of old interfaces." and the follow-up r254356: "Fix a bug in MachineBlockPlacement that may cause assertion failure during BranchProbability construction." Asserts were firing in Chromium builds. See PR25687. llvm-svn: 254366
* Replace all weight-based interfaces in MBB with probability-based ↵Cong Hou2015-12-015-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interfaces, and update all uses of old interfaces. The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes (http://reviews.llvm.org/D13908). 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights (http://reviews.llvm.org/D14361). 3. Use new interfaces in all other passes. 4. Remove old interfaces. This patch is 3+4 above. In this patch, MBB won't provide weight-based interfaces any more, which are totally replaced by probability-based ones. The interface addSuccessor() is redesigned so that the default probability is unknown. We allow unknown probabilities but don't allow using it together with known probabilities in successor list. That is to say, we either have a list of successors with all known probabilities, or all unknown probabilities. In the latter case, we assume each successor has 1/N probability where N is the number of successors. An assertion checks if the user is attempting to add a successor with the disallowed mixed use as stated above. This can help us catch many misuses. All uses of weight-based interfaces are now updated to use probability-based ones. Differential revision: http://reviews.llvm.org/D14973 llvm-svn: 254348
* [ARM] For old thumb ISA like v4t, we cannot use PC directly in pop.Quentin Colombet2015-11-301-4/+23
| | | | | | Fix the epilogue emission to account for that. llvm-svn: 254325
* Revert "[ARM] Generate ABI_optimization_goals build attribute, as described ↵Renato Golin2015-11-285-100/+0
| | | | | | | | | in the ARM ARM." This reverts commit r254201 and r254202, as it broke test-suite, self-hosting and sanitizer tests on ARM buildbots. llvm-svn: 254234
* [ARM] Generate ABI_optimization_goals build attribute, as described in the ↵Artyom Skrobov2015-11-275-0/+100
| | | | | | | | | | | | | | | | | | | ARM ARM. Summary: Since this build attribute corresponds to a whole module, and different functions in a module may differ in the optimizations enabled for them, this attribute is emitted after all functions, and only in the case that the optimization goals for all functions match. Reviewers: logan, hans Subscribers: aemerson, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D14934 llvm-svn: 254201
* ARM: address WOA unsigned division overflow crashMartell Malone2015-11-263-31/+63
| | | | | | | | | Building on r253865 the crash is not limited to signed overflows. Disable custom handling of unsigned 32-bit and 64-bit integer divide. Add test cases for both 32-bit and 64-bit unsigned integer overflow. llvm-svn: 254158
* Let SelectionDAG start to use probability-based interface to add successors.Cong Hou2015-11-244-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | The patch in http://reviews.llvm.org/D13745 is broken into four parts: 1. New interfaces without functional changes. 2. Use new interfaces in SelectionDAG, while in other passes treat probabilities as weights. 3. Use new interfaces in all other passes. 4. Remove old interfaces. This the second patch above. In this patch SelectionDAG starts to use probability-based interfaces in MBB to add successors but other MC passes are still using weight-based interfaces. Therefore, we need to maintain correct weight list in MBB even when probability-based interfaces are used. This is done by updating weight list in probability-based interfaces by treating the numerator of probabilities as weights. This change affects many test cases that check successor weight values. I will update those test cases once this patch looks good to you. Differential revision: http://reviews.llvm.org/D14361 llvm-svn: 253965
* ARM: address WoA division overflow crashMartell Malone2015-11-233-23/+57
| | | | | | | Disable custom handling of signed 32-bit and 64-bit integer divide. Add test cases for both 32-bit and 64-bit integer overflow crashes. llvm-svn: 253865
OpenPOWER on IntegriCloud