summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/SPARC/64cond.ll
Commit message (Collapse)AuthorAgeFilesLines
* [Sparc] Return true in enableMultipleCopyHints().Jonas Paulsson2018-02-241-6/+7
| | | | | | | | | | Enable multiple COPY hints to eliminate more COPYs during register allocation. Note that this is something all targets should do, see https://reviews.llvm.org/D38128. Review: James Y Knight llvm-svn: 326028
* TableGen: fix operand counting for aliasesTim Northover2014-05-161-3/+3
| | | | | | | | | | | | | | | | | | | | | TableGen has a fairly dubious heuristic to decide whether an alias should be printed: does the alias have lest operands than the real instruction. This is bad enough (particularly with no way to override it), but it should at least be calculated consistently for both strings. This patch implements that logic: first get the *correct* string for the variant, in the same way as the Matcher, without guessing; then count the number of whitespace chars. There are basically 4 changes this brings about after the previous commits; all of these appear to be good, so I have changed the tests: + ARM64: we print "neg X, Y" instead of "sub X, xzr, Y". + ARM64: we skip implicit "uxtx" and "uxtw" modifiers. + Sparc: we print "mov A, B" instead of "or %g0, A, B". + Sparc: we print "fcmpX A, B" instead of "fcmpX %fcc0, A, B" llvm-svn: 208969
* The SPARCv9 ABI returns a float in %f0.Jakob Stoklund Olesen2014-01-121-1/+1
| | | | | | | | | | | | | | | This is different from the argument passing convention which puts the first float argument in %f1. With this patch, all returned floats are treated as if the 'inreg' flag were set. This means multiple float return values get packed in %f0, %f1, %f2, ... Note that when returning a struct in registers, clang will set the 'inreg' flag on the return value, so that behavior is unchanged. This also happens when returning a float _Complex. llvm-svn: 199028
* [SparcV9]: Custom lower UMULO/SMULO so that the arguments are send to ↵Venkatraman Govindaraju2014-01-011-0/+5
| | | | | | __multi3() in correct order. llvm-svn: 198281
* [Sparc]: Implement getSetCCResultType() in SparcTargetLowering so that ↵Venkatraman Govindaraju2013-12-091-0/+14
| | | | | | umulo/smulo can be lowered on sparcv9 without an assertion error. llvm-svn: 196751
* Allocate local registers in order for optimal coloring.Andrew Trick2013-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also avoid locals evicting locals just because they want a cheaper register. Problem: MI Sched knows exactly how many registers we have and assumes they can be colored. In cases where we have large blocks, usually from unrolled loops, greedy coloring fails. This is a source of "regressions" from the MI Scheduler on x86. I noticed this issue on x86 where we have long chains of two-address defs in the same live range. It's easy to see this in matrix multiplication benchmarks like IRSmk and even the unit test misched-matmul.ll. A fundamental difference between the LLVM register allocator and conventional graph coloring is that in our model a live range can't discover its neighbors, it can only verify its neighbors. That's why we initially went for greedy coloring and added eviction to deal with the hard cases. However, for singly defined and two-address live ranges, we can optimally color without visiting neighbors simply by processing the live ranges in instruction order. Other beneficial side effects: It is much easier to understand and debug regalloc for large blocks when the live ranges are allocated in order. Yes, global allocation is still very confusing, but it's nice to be able to comprehend what happened locally. Heuristics could be added to bias register assignment based on instruction locality (think late register pairing, banks...). Intuituvely this will make some test cases that are on the threshold of register pressure more stable. llvm-svn: 187139
* Fix a typo in asm string of BP* family of instructions. With this fixRoman Divacky2013-06-071-2/+2
| | | | | | I am able to compile/assemble/link/run /bin/echo from FreeBSD. llvm-svn: 183537
* [Sparc]: Use cmp instruction instead of subcc to compare integers.Venkatraman Govindaraju2013-06-071-8/+8
| | | | llvm-svn: 183463
* Sparc: Combine add/or/sethi instruction with restore if possible.Venkatraman Govindaraju2013-06-021-4/+4
| | | | llvm-svn: 183088
* Sparc: Perform leaf procedure optimization by defaultVenkatraman Govindaraju2013-06-021-1/+1
| | | | llvm-svn: 183083
* Don't use %g0 to materialize 0 directly.Jakob Stoklund Olesen2013-05-191-0/+11
| | | | | | | | The wired physreg doesn't work on tied operands like on MOVXCC. Add a README note to fix this later. llvm-svn: 182225
* Select i64 values with %icc conditions.Jakob Stoklund Olesen2013-05-191-0/+11
| | | | llvm-svn: 182224
* Add floating point selects on %xcc predicates.Jakob Stoklund Olesen2013-05-191-0/+22
| | | | llvm-svn: 182222
* Implement SPselectfcc for i64 operands.Jakob Stoklund Olesen2013-05-191-0/+11
| | | | | | | Also clean up the arguments to all the MOVCC instructions so the operands always are (true-val, false-val, cond-code). llvm-svn: 182221
* Recognize sparc64 as an alias for sparcv9 triples.Jakob Stoklund Olesen2013-05-141-2/+2
| | | | | | Patch by Brad Smith! llvm-svn: 181808
* Add SPARC v9 support for select on 64-bit compares.Jakob Stoklund Olesen2013-04-041-0/+22
| | | | | | | | | | | This requires v9 cmov instructions using the %xcc flags instead of the %icc flags. Still missing: - Select floats on %xcc flags. - Select i64 on %fcc flags. llvm-svn: 178737
* Add 64-bit compare + branch for SPARC v9.Jakob Stoklund Olesen2013-04-031-0/+34
The same compare instruction is used for 32-bit and 64-bit compares. It sets two different sets of flags: icc and xcc. This patch adds a conditional branch instruction using the xcc flags for 64-bit compares. llvm-svn: 178621
OpenPOWER on IntegriCloud