summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/AArch64/AArch64FastISel.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [FastISel][AArch64] Add target-specific lowering for logical operations.Juergen Ributzka2014-09-041-26/+163
| | | | | | | | | This change adds support for immediate and shift-left folding into logical operations. This fixes rdar://problem/18223183. llvm-svn: 217118
* [FastISel][tblgen] Rename tblgen generated FastISel functions. NFC.Juergen Ributzka2014-09-031-33/+33
| | | | | | | | | | This is the final round of renaming. This changes tblgen to emit lower-case function names for FastEmitInst_* and FastEmit_*, and updates all its uses in the source code. Reviewed by Eric llvm-svn: 217075
* [FastISel] Rename public visible FastISel functions. NFC.Juergen Ributzka2014-09-031-43/+43
| | | | | | | | | | | | | | | | | | | | | This commit renames the following public FastISel functions: LowerArguments -> lowerArguments SelectInstruction -> selectInstruction TargetSelectInstruction -> fastSelectInstruction FastLowerArguments -> fastLowerArguments FastLowerCall -> fastLowerCall FastLowerIntrinsicCall -> fastLowerIntrinsicCall FastEmitZExtFromI1 -> fastEmitZExtFromI1 FastEmitBranch -> fastEmitBranch UpdateValueMap -> updateValueMap TargetMaterializeConstant -> fastMaterializeConstant TargetMaterializeAlloca -> fastMaterializeAlloca TargetMaterializeFloatZero -> fastMaterializeFloatZero LowerCallTo -> lowerCallTo Reviewed by Eric llvm-svn: 217074
* [FastISel] Some long overdue spring cleaning of FastISel.Juergen Ributzka2014-09-031-30/+30
| | | | | | | | | | | | | Things got a little bit messy over the years and it is time for a little bit spring cleaning. This first commit is focused on the FastISel base class itself. It doxyfies all comments, C++11fies the code where it makes sense, renames internal methods to adhere to the coding standard, and clang-formats the files. Reviewed by Eric llvm-svn: 217060
* [FastISel][AArch64] Move unconditional branch handling into 'SelectBranch'. NFC.Juergen Ributzka2014-09-031-9/+7
| | | | llvm-svn: 217054
* [FastISel][AArch64] Add target-dependent instruction selection for Add/Sub.Juergen Ributzka2014-09-031-187/+164
| | | | | | | | | | | There is already target-dependent instruction selection support for Adds/Subs to support compares and the intrinsics with overflow check. This takes advantage of the existing infrastructure to also support Add/Sub, which allows the folding of immediates, sign-/zero-extends, and shifts. This fixes rdar://problem/18207316. llvm-svn: 217007
* [FastISel][AArch64] Use the target-dependent selection code for shifts first.Juergen Ributzka2014-09-021-6/+6
| | | | | | | | | | | | This uses the target-dependent selection code for shifts first, which allows us to create better code for shifts with immediates and sign-/zero-extend folding. Vector type are not handled yet and the code falls back to target-independent instruction selection for these cases. This fixes rdar://problem/17907920. llvm-svn: 216985
* [FastISel][AArch64] Use a new helper function to determine if a value type ↵Juergen Ributzka2014-09-021-6/+25
| | | | | | | | | | | | is supported. NFCI. FastISel for AArch64 supports more value types than are actually legal. Use a dedicated helper function to reflect this. It is very similar to the isLoadStoreTypeLegal function, with the exception that vector types are not supported yet. llvm-svn: 216984
* [FastISel][AArch64] Move over to target-dependent instruction selection only.Juergen Ributzka2014-09-021-41/+133
| | | | | | | | | | | This change moves FastISel for AArch64 to target-dependent instruction selection only. This change replicates the existing target-independent behavior, therefore there are no changes to the unit tests or new tests. Future changes will take advantage of this change and update functionality and unit tests. llvm-svn: 216955
* [FastISel][AArch64] Use the correct register class for branches.Juergen Ributzka2014-08-291-7/+9
| | | | | | | | Also constrain the register class for branches. This fixes rdar://problem/18181496. llvm-svn: 216804
* [FastISel][AArch64] Fix an incorrect kill flag due to a bug in SelectTrunc.Juergen Ributzka2014-08-291-6/+13
| | | | | | | | | | | | | | | | | | | | When we select a trunc instruction we don't emit any code if the type is already i32 or smaller. This is because the instruction that uses the truncated value will deal with it. This behavior can incorrectly transfer a kill flag, which was meant for the result of the truncate, onto the source register. %2 = trunc i32 %1 to i16 ... = ... %2 -> ... = ... vreg1 <kill> ... = ... %1 ... = ... vreg1 This commit fixes this by emitting a COPY instruction, so that the result and source register are distinct virtual registers. This fixes rdar://problem/18178188. llvm-svn: 216750
* [FastISel][AArch64] Don't fold instructions that are not in the same basic ↵Juergen Ributzka2014-08-291-23/+38
| | | | | | | | | | | | | | | block. This fix checks first if the instruction to be folded (e.g. sign-/zero-extend, or shift) is in the same machine basic block as the instruction we are folding into. Not doing so can result in incorrect code, because the value might not be live-out of the basic block, where the value is defined. This fixes rdar://problem/18169495. llvm-svn: 216700
* Revert "[FastISel][AArch64] Don't fold instructions too aggressively into ↵Juergen Ributzka2014-08-271-92/+16
| | | | | | | | the memory operation." Quentin pointed out that this is not the correct approach and there is a better and easier solution. llvm-svn: 216632
* [FastISel][AArch64] Don't fold instructions too aggressively into the memory ↵Juergen Ributzka2014-08-271-16/+92
| | | | | | | | | | | | | | | | | | | | | operation. Currently instructions are folded very aggressively into the memory operation, which can lead to the use of killed operands: %vreg1<def> = ADDXri %vreg0<kill>, 2 %vreg2<def> = LDRBBui %vreg0, 2 ... = ... %vreg1 ... This usually happens when the result is also used by another non-memory instruction in the same basic block, or any instruction in another basic block. If the computed address is used by only memory operations in the same basic block, then it is safe to fold them. This is because all memory operations will fold the address computation and the original computation will never be emitted. This fixes rdar://problem/18142857. llvm-svn: 216629
* [FastISel][AArch64] Fix a comment in my previous commit (r216617).Juergen Ributzka2014-08-271-1/+1
| | | | llvm-svn: 216622
* [FastISel][AArch64] Fix simplify address when the address comes from a shift.Juergen Ributzka2014-08-271-0/+4
| | | | | | | | | When the address comes directly from a shift instruction then the address computation cannot be folded into the memory instruction, because the zero register is not available as a base register. Simplify addess needs to emit the shift instruction and use the result as base register. llvm-svn: 216621
* [FastISel][AArch64] Use the zero register for stores.Juergen Ributzka2014-08-271-5/+19
| | | | | | | | | Use the zero register directly when possible to avoid an unnecessary register copy and a wasted register at -O0. This also uses integer stores to store a positive floating-point zero. This saves us from materializing the positive zero in a register and then storing it. llvm-svn: 216617
* [FastISel][AArch64] Fix address simplification.Juergen Ributzka2014-08-271-8/+103
| | | | | | | | | | | | When a shift with extension or an add with shift and extension cannot be folded into the memory operation, then the address calculation has to be materialized separately. While doing so the code forgot to consider a possible sign-/zero- extension. This fix folds now also the sign-/zero-extension into the add or shift instruction which is used to materialize the address. This fixes rdar://problem/18141718. llvm-svn: 216511
* [FastISel][AArch64] Fold Sign-/Zero-Extend into the shift immediate instruction.Juergen Ributzka2014-08-271-55/+249
| | | | llvm-svn: 216510
* [FastISel][AArch64] Refactor float zero materialization. NFCI.Juergen Ributzka2014-08-251-20/+29
| | | | llvm-svn: 216403
* [FastISel][AArch64] Add support for variable shift.Juergen Ributzka2014-08-211-32/+141
| | | | | | | | This adds the missing variable shift support for value type i8, i16, and i32. This fixes <rdar://problem/18095685>. llvm-svn: 216242
* [FastISel][AArch64] Use the correct register class to make the MI verifier ↵Juergen Ributzka2014-08-211-135/+140
| | | | | | | | | | | | | | | happy. This is mostly achieved by providing the correct register class manually, because getRegClassFor always returns the GPR*AllRegClass for MVT::i32 and MVT::i64. Also cleanup the code to use the FastEmitInst_* method whenever possible. This makes sure that the operands' register class is properly constrained. For all the remaining cases this adds the missing constrainOperandRegClass calls for each operand. llvm-svn: 216225
* [FastISel][AArch64] Factor out ANDWri instruction generation into a helper ↵Juergen Ributzka2014-08-211-42/+50
| | | | | | function. NFCI. llvm-svn: 216199
* [FastISel][AArch64] Don't fold the sign-/zero-extend from i1 into the compare.Juergen Ributzka2014-08-201-7/+20
| | | | | | | | | | This fixes a bug I introduced in a previous commit (r216033). Sign-/Zero- extension from i1 cannot be folded into the ADDS/SUBS instructions. Instead both operands have to be sign-/zero-extended with separate instructions. Related to <rdar://problem/17913111>. llvm-svn: 216073
* Silencing an MSVC C4334 warning ('<<' : result of 32-bit shift implicitly ↵Aaron Ballman2014-08-201-1/+1
| | | | | | converted to 64 bits (was 64-bit shift intended?)). NFC. llvm-svn: 216067
* [FastISel][AArch64] Use the proper FMOV instruction to materialize a +0.0.Juergen Ributzka2014-08-201-1/+1
| | | | | | | | | | Use FMOVWSr/FMOVXDr instead of FMOVSr/FMOVDr, which have the proper register class to be used with the zero register. This makes the MachineInstruction verifier happy again. This is related to <rdar://problem/18027157>. llvm-svn: 216040
* [FastISel][AArch64] Factor out ADDS/SUBS instruction emission and add ↵Juergen Ributzka2014-08-191-224/+397
| | | | | | | | | | | | | support for extensions and shift folding. Factor out the ADDS/SUBS instruction emission code into helper functions and make the helper functions more clever to support most of the different ADDS/SUBS instructions the architecture support. This includes better immedediate support, shift folding, and sign-/zero-extend folding. This fixes <rdar://problem/17913111>. llvm-svn: 216033
* Reapply [FastISel][AArch64] Add support for more addressing modes (r215597).Juergen Ributzka2014-08-191-168/+289
| | | | | | | | | | | | | | | | | | | | | Note: This was originally reverted to track down a buildbot error. Reapply without any modifications. Original commit message: FastISel didn't take much advantage of the different addressing modes available to it on AArch64. This commit allows the ComputeAddress method to recognize more addressing modes that allows shifts and sign-/zero-extensions to be folded into the memory operation itself. For Example: lsl x1, x1, #3 --> ldr x0, [x0, x1, lsl #3] ldr x0, [x0, x1] sxtw x1, w1 lsl x1, x1, #3 --> ldr x0, [x0, x1, sxtw #3] ldr x0, [x0, x1] llvm-svn: 216013
* Reapply [FastISel][AArch64] Make use of the zero register when possible ↵Juergen Ributzka2014-08-191-1/+13
| | | | | | | | | | | | | | | | (r215591). Note: This was originally reverted to track down a buildbot error. Reapply without any modifications. Original commit message: This change materializes now the value "0" from the zero register. The zero register can be folded by several instruction, so no materialization is need at all. Fixes <rdar://problem/17924413>. llvm-svn: 216009
* [FastISel][AArch64] Fix a few BuildMI callsites where the result register ↵Juergen Ributzka2014-08-191-8/+5
| | | | | | | | | | | | was added as an operand register. This fixes a few BuildMI callsites where the result register was added by using addReg, which is per default a use and therefore an operand register. Also use the zero register as result register when emitting a compare instruction (SUBS with unused result register). llvm-svn: 215997
* [FastISel][AArch64] Fix a latent bug in floating-point materialization.Juergen Ributzka2014-08-151-1/+10
| | | | | | | | | | | | | | | | | | | | | | The floating-point value positive zero (+0.0) is a valid immedate value according to isFPImmLegal. As a result AArch64 FastISel went ahead and used the immediate version of fmov to materialize the constant. The problem is that the immediate version of fmov cannot encode an imediate for postive zero. Instead a fmov from the zero register was supposed to be used in this case. This fix adds handling for this special case and uses fmov from the zero register to materialize a positive zero (negative zeroes go to the constant pool). There is no test case for this, because this code is currently dead. It will be enabled in a future commit and I will add a test case in a separate commit after that. This fixes <rdar://problem/18027157>. llvm-svn: 215753
* Reapplying [FastISel][AArch64] Cleanup constant materialization code. NFCI.Juergen Ributzka2014-08-151-26/+30
| | | | | | | | | | Note: This reapplies r215582 without any modifications. The refactoring wasn't responsible for the buildbot failures. Original commit message: Cleanup and prepare constant materialization code for future commits. llvm-svn: 215752
* Revert several FastISel commits to track down a buildbot error.Juergen Ributzka2014-08-141-42/+26
| | | | | | | | | | | | 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
* Revert "[FastISel][AArch64] Add support for more addressing modes."Juergen Ributzka2014-08-141-289/+168
| | | | | | This reverts commits r215597, because it might have broken the build bots. llvm-svn: 215659
* Silencing an MSVC C4334 warning ('<<' : result of 32-bit shift implicitly ↵Aaron Ballman2014-08-141-1/+1
| | | | | | converted to 64 bits (was 64-bit shift intended?)). NFC. llvm-svn: 215642
* AArch64: Silence warning in AArch64FastISelDavid Majnemer2014-08-141-1/+1
| | | | | | GCC was emitting a signed vs unsigned comparison warning. llvm-svn: 215620
* [AArch64, fast-isel] Fall back to SelectionDAG to select tail calls.Akira Hatanaka2014-08-131-0/+5
| | | | | | | | | | Certain functions such as objc_autoreleaseReturnValue have to be called as tail-calls even at -O0. Since normal fast-isel doesn't emit calls as tail calls, we have to fall back to SelectionDAG to select calls that are marked as tail. <rdar://problem/17991614> llvm-svn: 215600
* [FastISel][AArch64] Add support for more addressing modes.Juergen Ributzka2014-08-131-168/+289
| | | | | | | | | | | | | | | | | FastISel didn't take much advantage of the different addressing modes available to it on AArch64. This commit allows the ComputeAddress method to recognize more addressing modes that allows shifts and sign-/zero-extensions to be folded into the memory operation itself. For Example: lsl x1, x1, #3 --> ldr x0, [x0, x1, lsl #3] ldr x0, [x0, x1] sxtw x1, w1 lsl x1, x1, #3 --> ldr x0, [x0, x1, sxtw #3] ldr x0, [x0, x1] llvm-svn: 215597
* [FastISel][AArch64] Make use of the zero register when possible.Juergen Ributzka2014-08-131-1/+13
| | | | | | | | | | This change materializes now the value "0" from the zero register. The zero register can be folded by several instruction, so no materialization is need at all. Fixes <rdar://problem/17924413>. llvm-svn: 215591
* [FastISel][AArch64] Cleanup constant materialization code. NFCI.Juergen Ributzka2014-08-131-26/+30
| | | | | | Cleanup and prepare constant materialization code for future commits. llvm-svn: 215582
* [FastISel][AArch64] Attach MachineMemOperands to load and store instructions.Juergen Ributzka2014-08-081-17/+29
| | | | llvm-svn: 215231
* Remove the target machine from CCState. Previously it was only usedEric Christopher2014-08-061-4/+3
| | | | | | | | | to get the subtarget and that's accessible from the MachineFunction now. This helps clear the way for smaller changes where we getting a subtarget will require passing in a MachineFunction/Function as well. llvm-svn: 214988
* [FastIsel][AArch64] Fix previous commit r214844 (Don't perform ↵Juergen Ributzka2014-08-051-6/+4
| | | | | | | | | | | | | | sign-/zero-extension for function arguments that have already been sign-/zero-extended.) The original code would fail for unsupported value types like i1, i8, and i16. This fix changes the code to only create a sub-register copy for i64 value types and all other types (i1/i8/i16/i32) just use the source register without any modifications. getRegClassFor() is now guarded by the i64 value type check, that guarantees that we always request a register for a valid value type. llvm-svn: 214848
* [FastISel][AArch64] Implement the FastLowerArguments hook.Juergen Ributzka2014-08-051-0/+103
| | | | | | | | | | | | | This implements basic argument lowering for AArch64 in FastISel. It only handles a small subset of the C calling convention. It supports simple arguments that can be passed in GPR and FPR registers. This should cover most of the trivial cases without falling back to SelectionDAG. This fixes <rdar://problem/17890986>. llvm-svn: 214846
* [FastISel][AArch64] Don't perform sign-/zero-extension for function ↵Juergen Ributzka2014-08-051-2/+24
| | | | | | arguments that have already been sign-/zero-extended. llvm-svn: 214844
* [FastISel][AArch64] Fix shift lowering for i8 and i16 value types.Juergen Ributzka2014-08-041-15/+13
| | | | | | | | | | | | | | | This fix changes the parameters #r and #s that are passed to the UBFM/SBFM instruction to get the zero/sign-extension for free. The original problem was that the shift left would use the 32-bit shift even for i8/i16 value types, which could leave the upper bits set with "garbage" values. The arithmetic shift right on the other side would use the wrong MSB as sign-bit to determine what bits to shift into the value. This fixes <rdar://problem/17907720>. llvm-svn: 214788
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-1/+2
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [FastISel][AArch64] Fold offset into the memory operation.Juergen Ributzka2014-08-011-0/+7
| | | | | | | | | | | | Fold simple offsets into the memory operation: add x0, x0, #8 ldr x0, [x0] --> ldr x0, [x0, #8] Fixes <rdar://problem/17887945>. llvm-svn: 214545
* [FastISel][AArch64] Add branch weights.Juergen Ributzka2014-08-011-5/+38
| | | | | | | | | Add branch weights to branch instructions, so that the following passes can optimize based on it (i.e. basic block ordering). Fixes <rdar://problem/17887137>. llvm-svn: 214537
* [FastISel][AArch64] Fix the immediate versions of the ↵Juergen Ributzka2014-08-011-48/+49
| | | | | | | | | | | | {s|u}{add|sub}.with.overflow intrinsics. ADDS and SUBS cannot encode negative immediates or immediates larger than 12bit. This fix checks if the immediate version can be used under this constraints and if we can convert ADDS to SUBS or vice versa to support negative immediates. Also update the test cases to test the immediate versions. llvm-svn: 214470
OpenPOWER on IntegriCloud