summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/PowerPC/fma.ll
Commit message (Collapse)AuthorAgeFilesLines
* PowerPC: Do not use llc -march in tests.Matthias Braun2017-08-011-1/+1
| | | | | | | | | | | | | | | | | | | | | `llc -march` is problematic because it only switches the target architecture, but leaves the operating system unchanged. This occasionally leads to indeterministic tests because the OS from LLVM_DEFAULT_TARGET_TRIPLE is used. However we can simply always use `llc -mtriple` instead. This changes all the tests to do this to avoid people using -march when they copy and paste parts of tests. This patch: - Removes -march if the .ll file already has a matching `target triple` directive or -mtriple argument. - In all other cases changes -march=ppc32/-march=ppc64 to -mtriple=ppc32--/-mtriple=ppc64-- See also the discussion in https://reviews.llvm.org/D35287 llvm-svn: 309754
* Adding -verify-machineinstrs option to PowerPC testsEhsan Amiri2016-08-031-4/+4
| | | | | | | | | | | Currently we have a number of tests that fail with -verify-machineinstrs. To detect this cases earlier we add the option to the testcases with the exception of tests that will currently fail with this option. PR 27456 keeps track of this failures. No code review, as discussed with Hal Finkel. llvm-svn: 277624
* [PPCVSXFMAMutate] Temporarily disable this passTim Shen2016-03-031-4/+4
| | | | llvm-svn: 262573
* Add support for VSX FMA single-precision instructions to the PPC back endNemanja Ivanovic2015-05-291-0/+83
| | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D9941 It adds the various FMA instructions introduced in the version 2.07 of the ISA along with the testing for them. These are operations on single precision scalar values in VSX registers. llvm-svn: 238578
* [PowerPC] Re-enable VSX test line for fma.ll with -mcpu=pwr7Bill Schmidt2014-10-191-3/+1
| | | | | | | | | | | The VSX testing variant in test/CodeGen/PowerPC/fma.ll had to be disabled because of unexpected behavior on many of the builders. I tracked this down to a situation that occurs when the VSX attribute is enabled for a target that disables the MI early scheduling pass. This patch adds -mcpu=pwr7 to make this predictable. The other issue will be addressed separately. llvm-svn: 220171
* [PowerPC] Disable +vsx RUN line for fma.ll due to inconsistency on other ↵Bill Schmidt2014-10-171-1/+3
| | | | | | builders llvm-svn: 220094
* [PowerPC] Change liveness testing in VSX FMA mutation passBill Schmidt2014-10-171-1/+37
| | | | | | | | | | | | | | | | With VSX enabled, LLVM crashes when compiling test/CodeGen/PowerPC/fma.ll. I traced this to the liveness test that's revised in this patch. The interval test is designed to only work for virtual registers, but in this case the AddendSrcReg is physical. Since there is already a walk of the MIs between the AddendMI and the FMA, I added a check for def/kill of the AddendSrcReg in that loop. At Hal Finkel's request, I converted the liveness test to an assert restricted to virtual registers. I've changed the fma.ll test to have VSX and non-VSX variants so we can test both kinds of multiply-adds. llvm-svn: 220090
* Optionally enable more-aggressive FMA formation in DAGCombineHal Finkel2014-09-191-3/+18
| | | | | | | | | | | | | | | | | The heuristic used by DAGCombine to form FMAs checks that the FMUL has only one use, but this is overly-conservative on some systems. Specifically, if the FMA and the FADD have the same latency (and the FMA does not compete for resources with the FMUL any more than the FADD does), there is no need for the restriction, and furthermore, forming the FMA leaving the FMUL can still allow for higher overall throughput and decreased critical-path length. Here we add a new TLI callback, enableAggressiveFMAFusion, false by default, to elide the hasOneUse check. This is enabled for PowerPC by default, as most PowerPC systems will benefit. Patch by Olivier Sallenave, thanks! llvm-svn: 218120
* Convert CodeGen/*/*.ll tests to use the new CHECK-LABEL for easier ↵Stephen Lin2013-07-131-8/+8
| | | | | | | | | | debugging. No functionality change and all tests pass after conversion. This was done with the following sed invocation to catch label lines demarking function boundaries: sed -i '' "s/^;\( *\)\([A-Z0-9_]*\):\( *\)test\([A-Za-z0-9_-]*\):\( *\)$/;\1\2-LABEL:\3test\4:\5/g" test/CodeGen/*/*.ll which was written conservatively to avoid false positives rather than false negatives. I scanned through all the changes and everything looks correct. llvm-svn: 186258
* FileCheckize a bunch of tests.Benjamin Kramer2013-04-111-2/+25
| | | | llvm-svn: 179276
* Convert all tests using TCL-style quoting to use shell-style quoting.Chandler Carruth2012-07-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This was done through the aid of a terrible Perl creation. I will not paste any of the horrors here. Suffice to say, it require multiple staged rounds of replacements, state carried between, and a few nested-construct-parsing hacks that I'm not proud of. It happens, by luck, to be able to deal with all the TCL-quoting patterns in evidence in the LLVM test suite. If anyone is maintaining large out-of-tree test trees, feel free to poke me and I'll send you the steps I used to convert things, as well as answer any painful questions etc. IRC works best for this type of thing I find. Once converted, switch the LLVM lit config to use ShTests the same as Clang. In addition to being able to delete large amounts of Python code from 'lit', this will also simplify the entire test suite and some of lit's architecture. Finally, the test suite runs 33% faster on Linux now. ;] For my 16-hardware-thread (2x 4-core xeon e5520): 36s -> 24s llvm-svn: 159525
* Rename fp-op fusion option (yet again) for compatibility with GCC option.Lang Hames2012-06-221-1/+1
| | | | llvm-svn: 159042
* Rename -allow-excess-fp-precision flag to -fuse-fp-ops, and switch from aLang Hames2012-06-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | boolean flag to an enum: { Fast, Standard, Strict } (default = Standard). This option controls the creation by optimizations of fused FP ops that store intermediate results in higher precision than IEEE allows (E.g. FMAs). The behavior of this option is intended to match the behaviour specified by a soon-to-be-introduced frontend flag: '-ffuse-fp-ops'. Fast mode - allows formation of fused FP ops whenever they're profitable. Standard mode - allow fusion only for 'blessed' FP ops. At present the only blessed op is the fmuladd intrinsic. In the future more blessed ops may be added. Strict mode - allow fusion only if/when it can be proven that the excess precision won't effect the result. Note: This option only controls formation of fused ops by the optimizers. Fused operations that are explicitly requested (e.g. FMA via the llvm.fma.* intrinsic) will always be honored, regardless of the value of this option. Internally TargetOptions::AllowExcessFPPrecision has been replaced by TargetOptions::AllowFPOpFusion. llvm-svn: 158956
* Add DAG-combines for aggressive FMA formation.Lang Hames2012-06-191-1/+1
| | | | | | | | | | | | | | | | | | | | This patch adds DAG combines to form FMAs from pairs of FADD + FMUL or FSUB + FMUL. The combines are performed when: (a) Either AllowExcessFPPrecision option (-enable-excess-fp-precision for llc) OR UnsafeFPMath option (-enable-unsafe-fp-math) are set, and (b) TargetLoweringInfo::isFMAFasterThanMulAndAdd(VT) is true for the type of the FADD/FSUB, and (c) The FMUL only has one user (the FADD/FSUB). If your target has fast FMA instructions you can make use of these combines by overriding TargetLoweringInfo::isFMAFasterThanMulAndAdd(VT) to return true for types supported by your FMA instruction, and adding patterns to match ISD::FMA to your FMA instructions. llvm-svn: 158757
* Eliminate more uses of llvm-as and llvm-dis.Dan Gohman2009-09-091-1/+1
| | | | llvm-svn: 81293
* Split the Add, Sub, and Mul instruction opcodes into separateDan Gohman2009-06-041-20/+20
| | | | | | | | | | | | | | | integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897
* Remove llvm-upgrade and update tests.Tanya Lattner2008-02-191-29/+36
| | | | llvm-svn: 47325
* Convert tests using "| wc -l | grep ..." to use the count script.Dan Gohman2007-08-151-1/+1
| | | | llvm-svn: 41097
* For PR1319: Upgrade to new test harness.Reid Spencer2007-04-151-1/+2
| | | | llvm-svn: 36087
* Regression is gone, don't try to find it on clean target.Reid Spencer2007-01-171-0/+46
llvm-svn: 33296
OpenPOWER on IntegriCloud