summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/ARM/fast-isel-intrinsic.ll
Commit message (Collapse)AuthorAgeFilesLines
* Reapply [FastISel] Let the target decide first if it wants to materialize a ↵Juergen Ributzka2014-08-191-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constant (215588). Note: This was originally reverted to track down a buildbot error. This commit exposed a latent bug that was fixed in r215753. Therefore it is reapplied without any modifications. I run it through SPEC2k and SPEC2k6 for AArch64 and it didn't introduce any new regeressions. Original commit message: This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 216006
* Revert several FastISel commits to track down a buildbot error.Juergen Ributzka2014-08-141-0/+4
| | | | | | | | | | | | This reverts: r215595 "[FastISel][X86] Add large code model support for materializing floating-point constants." r215594 "[FastISel][X86] Use XOR to materialize the "0" value." r215593 "[FastISel][X86] Emit more efficient instructions for integer constant materialization." r215591 "[FastISel][AArch64] Make use of the zero register when possible." r215588 "[FastISel] Let the target decide first if it wants to materialize a constant." r215582 "[FastISel][AArch64] Cleanup constant materialization code. NFCI." llvm-svn: 215673
* [FastISel] Let the target decide first if it wants to materialize a constant.Juergen Ributzka2014-08-131-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | This changes the order in which FastISel tries to materialize a constant. Originally it would try to use a simple target-independent approach, which can lead to the generation of inefficient code. On X86 this would result in the use of movabsq to materialize any 64bit integer constant - even for simple and small values such as 0 and 1. Also some very funny floating-point materialization could be observed too. On AArch64 it would materialize the constant 0 in a register even the architecture has an actual "zero" register. On ARM it would generate unnecessary mov instructions or not use mvn. This change simply changes the order and always asks the target first if it likes to materialize the constant. This doesn't fix all the issues mentioned above, but it enables the targets to implement such optimizations. Related to <rdar://problem/17420988>. llvm-svn: 215588
* Un-XFAILify some tests which are now passing.Bill Wendling2013-12-291-2/+0
| | | | llvm-svn: 198184
* ARM: use CHECK-LABEL on a test.Tim Northover2013-11-221-20/+20
| | | | llvm-svn: 195457
* [PR17978] Mark two ARM/fast-isel tests as XFAIL:vg_leak due to GV.NAKAMURA Takumi2013-11-181-0/+2
| | | | llvm-svn: 195010
* ARM: Fast-isel register class constrain for extends.Jim Grosbach2013-08-161-2/+2
| | | | | | | | | | Properly constrain the operand register class for instructions used in [sz]ext expansion. Update more tests to use the verifier now that we're getting the register classes correct. rdar://12594152 llvm-svn: 188594
* ARM: Clean up fast-isel machine verifier errors.Jim Grosbach2013-08-161-4/+4
| | | | | | | | | | | | | Lots of machine verifier errors result from using a plain GPR regclass for incoming argument copies. A more restrictive rGPR class is more appropriate since it more accurately represents what's happening, plus it lines up better with isel later on so the verifier is happier. Reduces the number of ARM fast-isel tests not running with the verifier enabled by over half. rdar://12594152 llvm-svn: 188592
* Enable FastISel on ARM for Linux and NaCl, not MCJITJF Bastien2013-06-141-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a resubmit of r182877, which was reverted because it broken MCJIT tests on ARM. The patch leaves MCJIT on ARM as it was before: only enabled for iOS. I've CC'ed people from the original review and revert. FastISel was only enabled for iOS ARM and Thumb2, this patch enables it for ARM (not Thumb2) on Linux and NaCl, but not MCJIT. Thumb2 support needs a bit more work, mainly around register class restrictions. The patch punts to SelectionDAG when doing TLS relocation on non-Darwin targets. I will fix this and other FastISel-to-SelectionDAG failures in a separate patch. The patch also forces FastISel to retain frame pointers: iOS always keeps them for backtracking (so emitted code won't change because of this), but Linux was getting much worse code that was incorrect when using big frames (such as test-suite's lencod). I'll also fix this in a later patch, it will probably require a peephole so that FastISel doesn't rematerialize frame pointers back-to-back. The test changes are straightforward, similar to: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130513/174279.html They also add a vararg test that got dropped in that change. I ran all of lnt test-suite on A15 hardware with --optimize-option=-O0 and all the tests pass. All the tests also pass on x86 make check-all. I also re-ran the check-all tests that failed on ARM, and they all seem to pass. llvm-svn: 183966
* ARM FastISel integer sext/zext improvementsJF Bastien2013-06-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My recent ARM FastISel patch exposed this bug: http://llvm.org/bugs/show_bug.cgi?id=16178 The root cause is that it can't select integer sext/zext pre-ARMv6 and asserts out. The current integer sext/zext code doesn't handle other cases gracefully either, so this patch makes it handle all sext and zext from i1/i8/i16 to i8/i16/i32, with and without ARMv6, both in Thumb and ARM mode. This should fix the bug as well as make FastISel faster because it bails to SelectionDAG less often. See fastisel-ext.patch for this. fastisel-ext-tests.patch changes current tests to always use reg-imm AND for 8-bit zext instead of UXTB. This simplifies code since it is supported on ARMv4t and later, and at least on A15 both should perform exactly the same (both have exec 1 uop 1, type I). 2013-05-31-char-shift-crash.ll is a bitcode version of the above bug 16178 repro. fast-isel-ext.ll tests all sext/zext combinations that ARM FastISel should now handle. Note that my ARM FastISel enabling patch was reverted due to a separate failure when dealing with MCJIT, I'll fix this second failure and then turn FastISel on again for non-iOS ARM targets. I've tested "make check-all" on my x86 box, and "lnt test-suite" on A15 hardware. llvm-svn: 183551
* Revert r182937 and r182877.Rafael Espindola2013-05-301-8/+6
| | | | | | | | | r182877 broke MCJIT tests on ARM and r182937 was working around another failure by r182877. This should make the ARM bots green. llvm-svn: 182960
* Enable FastISel on ARM for Linux and NaClJF Bastien2013-05-291-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | FastISel was only enabled for iOS ARM and Thumb2, this patch enables it for ARM (not Thumb2) on Linux and NaCl. Thumb2 support needs a bit more work, mainly around register class restrictions. The patch punts to SelectionDAG when doing TLS relocation on non-Darwin targets. I will fix this and other FastISel-to-SelectionDAG failures in a separate patch. The patch also forces FastISel to retain frame pointers: iOS always keeps them for backtracking (so emitted code won't change because of this), but Linux was getting much worse code that was incorrect when using big frames (such as test-suite's lencod). I'll also fix this in a later patch, it will probably require a peephole so that FastISel doesn't rematerialize frame pointers back-to-back. The test changes are straightforward, similar to: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130513/174279.html They also add a vararg test that got dropped in that change. I ran all of test-suite on A15 hardware with --optimize-option=-O0 and all the tests pass. llvm-svn: 182877
* Fix ARM FastISel tests, as a first step to enabling ARM FastISelDerek Schuff2013-05-141-32/+40
| | | | | | | | | | | | | | | | | | | | | ARM FastISel is currently only enabled for iOS non-Thumb1, and I'm working on enabling it for other targets. As a first step I've fixed some of the tests. Changes to ARM FastISel tests: - Different triples don't generate the same relocations (especially movw/movt versus constant pool loads). Use a regex to allow either. - Mangling is different. Use a regex to allow either. - The reserved registers are sometimes different, so registers get allocated in a different order. Capture the names only where this occurs. - Add -verify-machineinstrs to some tests where it works. It doesn't work everywhere it should yet. - Add -fast-isel-abort to many tests that didn't have it before. - Split out the VarArg test from fast-isel-call.ll into its own test. This simplifies test setup because of --check-prefix. Patch by JF Bastien llvm-svn: 181801
* [fast-isel] Add support for the expect intrinsic.Chad Rosier2013-03-071-0/+12
| | | | | | rdar://13370942 llvm-svn: 176649
* Comment out the rdar number.Chad Rosier2013-02-181-1/+1
| | | | llvm-svn: 175460
* [fast-isel] Remove an invalid assert.Chad Rosier2013-02-181-0/+7
| | | | | | | | If the memcpy has an odd length with an alignment of 2, this would incorrectly assert on the last 1 byte copy. rdar://13202135 llvm-svn: 175459
* [arm fast-isel] Make the fast-isel implementation of memcpy respect alignment.Chad Rosier2012-12-061-3/+94
| | | | | | rdar://12821569 llvm-svn: 169460
* [arm-fast-isel] Add support for -arm-long-calls.Chad Rosier2012-06-121-0/+32
| | | | | | Patch by Jush Lu <jush.msn@gmail.com>. llvm-svn: 158368
* Use getRegForValue() to materialize the address of ARM globals.Jakob Stoklund Olesen2012-01-071-16/+10
| | | | | | | | | This enables basic local CSE, giving us 20% smaller code for consumer-typeset in -O0 builds. <rdar://problem/10658692> llvm-svn: 147720
* Use movw+movt in ARMFastISel::ARMMaterializeGV.Jakob Stoklund Olesen2012-01-071-10/+20
| | | | | | | | | | | | | This eliminates a lot of constant pool entries for -O0 builds of code with many global variable accesses. This speeds up -O0 codegen of consumer-typeset by 2x because the constant island pass no longer has to look at thousands of constant pool entries. <rdar://problem/10629774> llvm-svn: 147712
* ARM target code clean up. Check for iOS, not Darwin where it makes sense.Evan Cheng2011-12-201-2/+2
| | | | llvm-svn: 146981
* Add support for inlining small memcpys.Chad Rosier2011-11-141-3/+31
| | | | | | rdar://10412592 llvm-svn: 144578
* The order in which the predicate is added differs between Thumb and ARM ↵Chad Rosier2011-11-131-3/+4
| | | | | | mode. Fix predicate when in ARM mode and restore SelectIntrinsicCall. llvm-svn: 144494
* Temporarily disable SelectIntrinsicCall when in ARM mode. This is causing ↵Chad Rosier2011-11-131-1/+0
| | | | | | failures. llvm-svn: 144492
* Add support in fast-isel for selecting memset/memcpy/memmove intrinsics.Chad Rosier2011-11-111-0/+78
llvm-svn: 144426
OpenPOWER on IntegriCloud