summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/ARM/fast-isel-call.ll
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Revert "Map DynamicNoPIC to Static on non-darwin.""Renato Golin2016-05-281-8/+18
| | | | | | | | This reverts commit r271096, as reverting it broke even more buildbots! But that also means I'll break on ARM again... :( llvm-svn: 271099
* Revert "Map DynamicNoPIC to Static on non-darwin."Renato Golin2016-05-281-18/+8
| | | | | | This reverts commit r271052, as it broke some ARM buildbots. llvm-svn: 271096
* Map DynamicNoPIC to Static on non-darwin.Rafael Espindola2016-05-271-8/+18
| | | | | | | DynamicNoPIC was only every used on darwin. This maps it to static on ELF. It matches what is done on X86. llvm-svn: 271052
* [ARM] Define a subtarget feature and use it to decide whether long calls shouldAkira Hatanaka2015-07-071-3/+3
| | | | | | | | | | | | | | | | | be emitted. This is needed to enable ARM long calls for LTO and enable and disable it on a per-function basis. Out-of-tree projects currently using EnableARMLongCalls to emit long calls should start passing "+long-calls" to the feature string (see the changes made to clang in r241565). rdar://problem/21529937 Differential Revision: http://reviews.llvm.org/D9364 llvm-svn: 241566
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
* Change the fast-isel-abort option from bool to int to enable "levels"Mehdi Amini2015-02-271-9/+9
| | | | | | | | | | | | | | | | | | | | | | | Summary: Currently fast-isel-abort will only abort for regular instructions, and just warn for function calls, terminators, function arguments. There is already fast-isel-abort-args but nothing for calls and terminators. This change turns the fast-isel-abort options into an integer option, so that multiple levels of strictness can be defined. This will help no being surprised when the "abort" option indeed does not abort, and enables the possibility to write test that verifies that no intrinsics are forgotten by fast-isel. Reviewers: resistor, echristo Subscribers: jfb, llvm-commits Differential Revision: http://reviews.llvm.org/D7941 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 230775
* Reapply [FastISel] Let the target decide first if it wants to materialize a ↵Juergen Ributzka2014-08-191-6/+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/+6
| | | | | | | | | | | | 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-6/+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
* [FastISel][ARM] Do not emit stores for undef arguments.Juergen Ributzka2014-08-011-0/+15
| | | | | | | | This is a followup patch for r214366, which added the same behavior to the AArch64 and X86 FastISel code. This fix reproduces the already existing behavior of SelectionDAG in FastISel. llvm-svn: 214531
* Un-XFAILify some tests which are now passing.Bill Wendling2013-12-291-2/+0
| | | | llvm-svn: 198184
* [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-9/+9
| | | | | | | | | | 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
* DebugInfo: Don't lose unreferenced non-trivial by-value parametersDavid Blaikie2013-06-211-1/+1
| | | | | | | | | | | | A FastISel optimization was causing us to emit no information for such parameters & when they go missing we end up emitting a different function type. By avoiding that shortcut we not only get types correct (very important) but also location information (handy) - even if it's only live at the start of a function & may be clobbered later. Reviewed/discussion by Evan Cheng & Dan Gohman. llvm-svn: 184604
* Enable FastISel on ARM for Linux and NaCl, not MCJITJF Bastien2013-06-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+0
| | | | | | | | | 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-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-99/+60
| | | | | | | | | | | | | | | | | | | | | 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
* [arm-fast-isel] Add support for fastcc.Jush Lu2012-08-161-0/+66
| | | | | | | | Without fastcc support, the caller just falls through to CallingConv::C for fastcc, but callee still uses fastcc, this inconsistency of calling convention is a problem, and fastcc support can fix it. llvm-svn: 162013
* [arm-fast-isel] Add support for vararg function calls.Jush Lu2012-07-191-0/+43
| | | | llvm-svn: 160500
* Revert r159804, "[arm-fast-isel] Add support for vararg function calls."NAKAMURA Takumi2012-07-061-43/+0
| | | | | | It broke LLVM :: CodeGen/Thumb2/large-call.ll on several hosts. llvm-svn: 159817
* [arm-fast-isel] Add support for vararg function calls.Jush Lu2012-07-061-0/+43
| | | | llvm-svn: 159804
* [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
* [arm-fast-isel] Add support for non-global callee.Chad Rosier2012-05-231-0/+20
| | | | | | Patch by Jush Lu <jush.msn@gmail.com>. llvm-svn: 157336
* ARM target code clean up. Check for iOS, not Darwin where it makes sense.Evan Cheng2011-12-201-2/+2
| | | | llvm-svn: 146981
* [arm-fast-isel] After promoting a function parameter be sure to update theChad Rosier2011-12-021-0/+46
| | | | | | | | argument value type. Otherwise, the sign/zero-extend has no effect on arguments passed via the stack (i.e., undefined high-order bits). rdar://10515467 llvm-svn: 145701
* Enable support for returning i1, i8, and i16. Nothing special todo as it's theChad Rosier2011-11-081-0/+15
| | | | | | | | callee's responsibility to sign or zero-extend the return value. The additional test case just checks to make sure the calls are selected (i.e., -fast-isel-abort doesn't assert). llvm-svn: 144047
* Add support for passing i1, i8, and i16 call parameters. Also, be sure toChad Rosier2011-11-051-0/+67
zero-extend the constant integer encoding. Test case provides testing for both call parameters and materialization of i1, i8, and i16 types. llvm-svn: 143821
OpenPOWER on IntegriCloud