summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/ARMISelLowering.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix return sequence on armv4 thumbJonathan Roelofs2014-08-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | POP on armv4t cannot be used to change thumb state (unilke later non-m-class architectures), therefore we need a different return sequence that uses 'bx' instead: POP {r3} ADD sp, #offset BX r3 This patch also fixes an issue where the return value in r3 would get clobbered for functions that return 128 bits of data. In that case, we generate this sequence instead: MOV ip, r3 POP {r3} ADD sp, #offset MOV lr, r3 MOV r3, ip BX lr http://reviews.llvm.org/D4748 llvm-svn: 214881
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-13/+23
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [SDAG] Let the DAG combiner take care of dead nodes rather than manuallyChandler Carruth2014-08-021-2/+0
| | | | | | | deleting them. This already seems to work, as no tests fail without this. llvm-svn: 214601
* Make sure no loads resulting from load->switch DAGCombine are marked invariantLouis Gerbarg2014-07-311-1/+1
| | | | | | | | | | | | | | Currently when DAGCombine converts loads feeding a switch into a switch of addresses feeding a load the new load inherits the isInvariant flag of the left side. This is incorrect since invariant loads can be reordered in cases where it is illegal to reoarder normal loads. This patch adds an isInvariant parameter to getExtLoad() and updates all call sites to pass in the data if they have it or false if they don't. It also changes the DAGCombine to use that data to make the right decision when creating the new load. llvm-svn: 214449
* ARM: add __aeabi_d2h for truncation on AEABI systemsTim Northover2014-07-291-0/+1
| | | | | | | ARM does actually define the name for this conversion, so we should use it on "-eabi" platforms. llvm-svn: 214176
* Add alignment value to allowsUnalignedMemoryAccessMatt Arsenault2014-07-271-4/+7
| | | | | | | | | | Rename to allowsMisalignedMemoryAccess. On R600, 8 and 16 byte accesses are mostly OK with 4-byte alignment, and don't need to be split into multiple accesses. Vector loads with an alignment of the element type are not uncommon in OpenCL code. llvm-svn: 214055
* [stack protector] Fix a potential security bug in stack protector where theAkira Hatanaka2014-07-251-0/+5
| | | | | | | | | | | | | | address of the stack guard was being spilled to the stack. Previously the address of the stack guard would get spilled to the stack if it was impossible to keep it in a register. This patch introduces a new target independent node and pseudo instruction which gets expanded post-RA to a sequence of instructions that load the stack guard value. Register allocator can now just remat the value when it can't keep it in a register. <rdar://problem/12475629> llvm-svn: 213967
* AA metadata refactoring (introduce AAMDNodes)Hal Finkel2014-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
* ARM: correct WoA __builtin_alloca handling on O0Saleem Abdulrasool2014-07-191-3/+2
| | | | | | | | | | | | | | | When performing a dynamic stack adjustment without optimisations, we would mark SP as def and R4 as kill. This occurred as part of the expansion of a WIN__CHKSTK SDNode which indicated the proper handling of SP and R4. The result would be that we would double define SP as part of an operation, which is obviously incorrect. Furthermore, the VTList for the chain had an incorrect parameter type of i32 instead of Other. Correct these to permit proper lowering of __builtin_alloca at -O0. llvm-svn: 213442
* ARM: support legalisation of "fptrunc ... to half" operations.Tim Northover2014-07-181-3/+7
| | | | llvm-svn: 213373
* ARM: support direct f16 <-> f64 conversionsTim Northover2014-07-171-1/+8
| | | | | | ARMv8 has instructions to handle it, otherwise a libcall is needed. llvm-svn: 213254
* CodeGen: extend f16 conversions to permit types > float.Tim Northover2014-07-171-2/+2
| | | | | | | | | | | | | | | | | | | This makes the two intrinsics @llvm.convert.from.f16 and @llvm.convert.to.f16 accept types other than simple "float". This is only strictly needed for the truncate operation, since otherwise double rounding occurs and there's no way to represent the strict IEEE conversion. However, for symmetry we allow larger types in the extend too. During legalization, we can expand an "fp16_to_double" operation into two extends for convenience, but abort when the truncate isn't legal. A new libcall is probably needed here. Even after this commit, various target tweaks are needed to actually use the extended intrinsics. I've put these into separate commits for clarity, so there are no actual tests of f64 conversion here. llvm-svn: 213248
* ARM: properly lower dllimport'ed global valuesSaleem Abdulrasool2014-07-071-2/+23
| | | | | | | | | | | | | | This completes the handling for DLL import storage symbols when lowering instructions. A DLL import storage symbol must have an additional load performed prior to use. This is applicable to variables and functions. This is particularly important for non-function symbols as it is possible to handle function references by emitting a thunk which performs the translation from the unprefixed __imp_ symbol to the proper symbol (although, this is a non-optimal lowering). For a variable symbol, no such thunk can be accommodated. llvm-svn: 212431
* Move function dependent resetting of a subtarget variable out of theEric Christopher2014-07-041-4/+6
| | | | | | | | | | subtarget. This involved having the movt predicate take the current function - since we care about size in instruction selection for whether or not to use movw/movt take the function so we can check the attributes. This required adding the current MachineFunction to FastISel and propagating through. llvm-svn: 212309
* [DAG] Pass the argument list to the CallLoweringInfo via move semantics. NFCI.Juergen Ributzka2014-07-011-3/+4
| | | | | | | | The argument list vector is never used after it has been passed to the CallLoweringInfo and moving it to the CallLoweringInfo is cleaner and pretty much as cheap as keeping a pointer to it. llvm-svn: 212135
* ARMEB: Vector extend operationsChristian Pirker2014-06-231-0/+5
| | | | | | Reviewed at http://reviews.llvm.org/D4043 llvm-svn: 211520
* Fix typosAlp Toker2014-06-191-1/+1
| | | | llvm-svn: 211304
* ARM: intrinsic support for rbit.Jim Grosbach2014-06-161-0/+5
| | | | | | | | | We already have an ARMISD node. Create an intrinsic to map to it so we can add support for the frontend __rbit() intrinsic. rdar://9283021 llvm-svn: 211057
* ARM: implement correct atomic operations on v7MTim Northover2014-06-161-8/+14
| | | | | | | | | | ARM v7M has ldrex/strex but not ldrexd/strexd. This means 32-bit operations should work as normal, but 64-bit ones are almost certainly doomed. Patch by Phoebe Buckheister. llvm-svn: 211042
* ARMEB: Fix trunc store for vector typesChristian Pirker2014-06-161-1/+2
| | | | | | Reviewed at http://reviews.llvm.org/D4135 llvm-svn: 211010
* ARM: Fix fastcc calling convention for Thumb1Oliver Stannard2014-06-131-3/+3
| | | | | | | | When targetting Thumb1 on a processor which has a VFP unit (which is not accessible from Thumb1), we were converting the fastcc calling convention to AAPCS-VFP, which is not possible. llvm-svn: 210889
* ARM: add VLA extension for WoA Itanium ABISaleem Abdulrasool2014-06-091-1/+106
| | | | | | | | | | | | | | | | The armv7-windows-itanium environment is nearly identical to the MSVC ABI. It has a few divergences, mostly revolving around the use of the Itanium ABI for C++. VLA support is one of the extensions that are amongst the set of the extensions. This adds support for proper VLA emission for this environment. This is somewhat similar to the handling for __chkstk emission on X86 and the large stack frame emission for ARM. The invocation style for chkstk is still controlled via the -mcmodel flag to clang. Make an explicit note that this is an extension. llvm-svn: 210489
* ARM: correct assertion for long-calls on WoASaleem Abdulrasool2014-06-071-2/+3
| | | | | | | | | | | COFF/PE, so the relocation model is never static. Loosen the assertion accordingly. The relocation can still be emitted properly, as it will be converted to an IMAGE_REL_ARM_ADDR32 which will be resolved by the loader taking the base relocation into account. This is necessary to permit the emission of long calls which can be controlled via the -mlong-calls option in the driver. llvm-svn: 210399
* ARMEB: Fix function return type f64Christian Pirker2014-06-011-0/+2
| | | | | | Reviewed at http://reviews.llvm.org/D3968 llvm-svn: 209990
* Have the TLOF creation take a Triple rather than needing a subtarget.Eric Christopher2014-05-311-4/+4
| | | | llvm-svn: 209937
* ARM: teach AAPCS-VFP to deal with Cortex-M4.Tim Northover2014-05-271-9/+8
| | | | | | | | | | | Cortex-M4 only has single-precision floating point support, so any LLVM "double" type will have been split into 2 i32s by now. Fortunately, the consecutive-register framework turns out to be precisely what's needed to reconstruct the double and follow AAPCS-VFP correctly! rdar://problem/17012966 llvm-svn: 209650
* SDAG: Legalize vector BSWAP into a shuffle if the shuffle is legal but the ↵Benjamin Kramer2014-05-191-0/+2
| | | | | | | | | | bswap not. - On ARM/ARM64 we get a vrev because the shuffle matching code is really smart. We still unroll anything that's not v4i32 though. - On X86 we get a pshufb with SSSE3. Required more cleverness in isShuffleMaskLegal. - On PPC we get a vperm for v8i16 and v4i32. v2i64 is unrolled. llvm-svn: 209123
* ARM: make libcall setup more table drivenSaleem Abdulrasool2014-05-181-161/+100
| | | | | | | | | Rather than create a series of function calls to setup the library calls, create a table with the information and just use the table to drive the configuration of the library calls. This makes it easier to both inspect the list as well as to modify it. NFC. llvm-svn: 209089
* ARM: consolidate frame pointer register knowledgeSaleem Abdulrasool2014-05-181-3/+5
| | | | | | | | | | | Use the ARMBaseRegisterInfo to query the frame register. The base register info is aware of the frame register that is used for the frame pointer. Use that to determine the frame register rather than duplicating the knowledge. Although, the code path is slightly different in that it may return SP, that can only occur if the frame pointer has been omitted in the machine function, which is supposed to contain the desired value in that case. llvm-svn: 209084
* Target: remove old constructors for CallLoweringInfoSaleem Abdulrasool2014-05-171-18/+17
| | | | | | | | | | This is mostly a mechanical change changing all the call sites to the newer chained-function construction pattern. This removes the horrible 15-parameter constructor for the CallLoweringInfo in favour of setting properties of the call via chained functions. No functional change beyond the removal of the old constructors are intended. llvm-svn: 209082
* ARM: use the proper target object format for WoASaleem Abdulrasool2014-05-171-1/+2
| | | | | | | | WoA uses COFF, not ELF. ARMISelLowering::createTLOF would previously return ELF for any non-MachO platform. This was a missed site when the original change for target format support for Windows on ARM was done. llvm-svn: 209057
* ARM: add some integer/floating point conversion libcallsSaleem Abdulrasool2014-05-161-0/+22
| | | | | | | | Add some Windows on ARM specific library calls. These are provided by msvcrt, and can be used to perform integer to floating-point conversions (and vice-versa) mirroring similar functions in the RTABI. llvm-svn: 208949
* Rename ComputeMaskedBits to computeKnownBits. "Masked" has beenJay Foad2014-05-141-8/+8
| | | | | | inappropriate since it lost its Mask parameter in r154011. llvm-svn: 208811
* ARM-BE: test files for vector argument passingChristian Pirker2014-05-141-1/+2
| | | | | | Reviewed at http://reviews.llvm.org/D3766 llvm-svn: 208793
* ARM: Implement big endian bit-conversion for NEON typeChristian Pirker2014-05-121-2/+8
| | | | llvm-svn: 208538
* Pass the value type to TLI::getRegisterByNameHal Finkel2014-05-111-1/+2
| | | | | | | | | | | | | We must validate the value type in TLI::getRegisterByName, because if we don't and the wrong type was used with the IR intrinsic, then we'll assert (because we won't be able to find a valid register class with which to construct the requested copy operation). For PPC64, additionally, the type information is necessary to decide between the 64-bit register and the 32-bit subregister. No functionality change. llvm-svn: 208508
* Add custom lowering for add/sub with overflow intrinsics to ARMLouis Gerbarg2014-05-091-0/+95
| | | | | | | | | | | | | This patch adds support to ARM for custom lowering of the llvm.{u|s}add.with.overflow.i32 intrinsics for i32/i64. This is particularly useful for handling idiomatic saturating math functions as generated by InstCombineCompare. Test cases included. rdar://14853450 llvm-svn: 208435
* ARM: HFAs must be passed in consecutive registersOliver Stannard2014-05-091-24/+117
| | | | | | | | | | When using the ARM AAPCS, HFAs (Homogeneous Floating-point Aggregates) must be passed in a block of consecutive floating-point registers, or on the stack. This means that unused floating-point registers cannot be back-filled with part of an HFA, however this can currently happen. This patch, along with the corresponding clang patch (http://reviews.llvm.org/D3083) prevents this. llvm-svn: 208413
* ARM: support PIC on Windows on ARMSaleem Abdulrasool2014-05-091-2/+26
| | | | | | | | Handle lowering of global addresses for PIC mode compilation on Windows. Always use the movw/movt load to load the address as Windows on ARM requires ARMv7+ and is a pure Thumb environment. llvm-svn: 208385
* ARM big endian function argument passingChristian Pirker2014-05-081-11/+30
| | | | llvm-svn: 208316
* Implememting named register intrinsicsRenato Golin2014-05-061-0/+11
| | | | | | | | | | | This patch implements the infrastructure to use named register constructs in programs that need access to specific registers (bare metal, kernels, etc). So far, only the stack pointer is supported as a technology preview, but as it is, the intrinsic can already support all non-allocatable registers from any architecture. llvm-svn: 208104
* Convert SelectionDAG::getMergeValues to use ArrayRef.Craig Topper2014-04-271-2/+2
| | | | llvm-svn: 207374
* Convert getMemIntrinsicNode to take ArrayRef of SDValue instead of pointer ↵Craig Topper2014-04-261-3/+2
| | | | | | and size. llvm-svn: 207329
* Convert SelectionDAG::getNode methods to use ArrayRef<SDValue>.Craig Topper2014-04-261-37/+27
| | | | llvm-svn: 207327
* DAGCombiner: Turn divs of vector splats into vectorized multiplications.Benjamin Kramer2014-04-261-0/+5
| | | | | | | | | | | | Otherwise the legalizer would just scalarize everything. Support for mulhi in the targets isn't that great yet so on most targets we get exactly the same scalarized output. Add a test for x86 vector udiv. I had to disable the mulhi nodes on ARM because there aren't any patterns for it. As far as I know ARM has instructions for getting the high part of a multiply so this should be fixed. llvm-svn: 207315
* [C++] Use 'nullptr'. Target edition.Craig Topper2014-04-251-18/+19
| | | | llvm-svn: 207197
* Add 'musttail' marker to call instructionsReid Kleckner2014-04-241-0/+3
| | | | | | | | | | | | This is similar to the 'tail' marker, except that it guarantees that tail call optimization will occur. It also comes with convervative IR verification rules that ensure that tail call optimization is possible. Reviewers: nicholas Differential Revision: http://llvm-reviews.chandlerc.com/D3240 llvm-svn: 207143
* ARM: disable emission of __XYZvfp in soft-float environment.Tim Northover2014-04-221-1/+1
| | | | | | | | | | The point of these calls is to allow Thumb-1 code to make use of the VFP unit to perform its operations. This is not desirable with -msoft-float, since most of the reasons you'd want that apply equally to the runtime library. rdar://problem/13766161 llvm-svn: 206874
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | definition below all of the header #include lines, lib/Target/... edition. llvm-svn: 206842
* Atomics: promote ARM's IR-based atomics pass to CodeGen.Tim Northover2014-04-171-0/+81
| | | | | | | | | | | | Still only 32-bit ARM using it at this stage, but the promotion allows direct testing via opt and is a reasonably self-contained patch on the way to switching ARM64. At this point, other targets should be able to make use of it without too much difficulty if they want. (See ARM64 commit coming soon for an example). llvm-svn: 206485
OpenPOWER on IntegriCloud