summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/ARMSubtarget.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [cleanup] Lift using directives, DEBUG_TYPE definitions, and even someChandler Carruth2014-04-221-2/+2
| | | | | | | | | | | | system headers above the includes of generated '.inc' files that actually contain code. In a few targets this was already done pretty consistently, but it wasn't done *really* consistently anywhere. It is strictly cleaner IMO and necessary in a bunch of places where the DEBUG_TYPE is referenced from the generated code. Consistency with the necessary places trumps. Hopefully the build bots are OK with the movement of intrin.h... llvm-svn: 206838
* [Modules] Make Support/Debug.h modular. This requires it to not changeChandler Carruth2014-04-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behavior based on other files defining DEBUG_TYPE, which means it cannot define DEBUG_TYPE at all. This is actually better IMO as it forces folks to define relevant DEBUG_TYPEs for their files. However, it requires all files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't already. I've updated all such files in LLVM and will do the same for other upstream projects. This still leaves one important change in how LLVM uses the DEBUG_TYPE macro going forward: we need to only define the macro *after* header files have been #include-ed. Previously, this wasn't possible because Debug.h required the macro to be pre-defined. This commit removes that. By defining DEBUG_TYPE after the includes two things are fixed: - Header files that need to provide a DEBUG_TYPE for some inline code can do so by defining the macro before their inline code and undef-ing it afterward so the macro does not escape. - We no longer have rampant ODR violations due to including headers with different DEBUG_TYPE definitions. This may be mostly an academic violation today, but with modules these types of violations are easy to check for and potentially very relevant. Where necessary to suppor headers with DEBUG_TYPE, I have moved the definitions below the includes in this commit. I plan to move the rest of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big enough. The comments in Debug.h, which were hilariously out of date already, have been updated to reflect the recommended practice going forward. llvm-svn: 206822
* ARM: update subtarget information for Windows on ARMSaleem Abdulrasool2014-04-021-0/+6
| | | | | | | Update the subtarget information for Windows on ARM. This enables using the MC layer to target Windows on ARM. llvm-svn: 205459
* ARM: cortex-m0 doesn't support unaligned memory access.Jim Grosbach2014-04-021-1/+6
| | | | | | | | | | | | Unlike other v6+ processors, cortex-m0 never supports unaligned accesses. From the v6m ARM ARM: "A3.2 Alignment support: ARMv6-M always generates a fault when an unaligned access occurs." rdar://16491560 llvm-svn: 205452
* ARM: add cyclone CPU with ZeroCycleZeroing feature.Tim Northover2014-04-011-0/+1
| | | | | | | | The Cyclone CPU is similar to swift for most LLVM purposes, but does have two preferred instructions for zeroing a VFP register. This teaches LLVM about them. llvm-svn: 205309
* Add ARM big endian Target (armeb, thumbeb)Christian Pirker2014-03-281-1/+3
| | | | | | Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
* ARM: enable tail call optimisation on Thumb 2Saleem Abdulrasool2014-03-111-1/+3
| | | | | | | | | | | | Tail call optimisation was previously disabled on all targets other than iOS5.0+. This enables the tail call optimisation on all Thumb 2 capable platforms. The test adjustments are to remove the IR hint "tail" to function invocation. The tests were designed assuming that tail call optimisations would not kick in which no longer holds true. llvm-svn: 203575
* Support: split object format out of environmentSaleem Abdulrasool2014-03-061-2/+3
| | | | | | | | | | | This is a preliminary setup change to support a renaming of Windows target triples. Split the object file format information out of the environment into a separate entity. Unfortunately, file format was previously treated as an environment with an unknown OS. This is most obvious in the ARM subtarget where the handling for macho on an arbitrary platform switches to AAPCS rather than APCS (as per Apple's needs). llvm-svn: 203160
* Use 16 byte stack alignment for NaCl on ARMMark Seaborn2014-02-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NaCl's ARM ABI uses 16 byte stack alignment, so set that in ARMSubtarget.cpp. Using 16 byte alignment exposes an issue in code generation in which a varargs function leaves a 4 byte gap between the values of r1-r3 saved to the stack and the following arguments that were passed on the stack. (Previously, this code only needed to support 4 byte and 8 byte alignment.) With this issue, llc generated: varargs_func: sub sp, sp, #16 push {lr} sub sp, sp, #12 add r0, sp, #16 // Should be 20 stm r0, {r1, r2, r3} ldr r0, .LCPI0_0 // Address of va_list add r1, sp, #16 str r1, [r0] bl external_func Fix the bug by checking for "Align > 4". Also simplify the code by using OffsetToAlignment(), and update comments. Differential Revision: http://llvm-reviews.chandlerc.com/D2677 llvm-svn: 201497
* Unaligned access is supported on ARMv6 and ARMv7 for the NetBSD target.Joerg Sonnenberger2014-02-021-3/+4
| | | | | | Patch from Matt Thomas. llvm-svn: 200654
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-071-1/+1
| | | | | | | | | | subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
* ARM MachO: sort out isTargetDarwin/isTargetIOS/... checks.Tim Northover2014-01-061-7/+7
| | | | | | | | | | | | | | | | | | The ARM backend has been using most of the MachO related subtarget checks almost interchangeably, and since the only target it's had to run on has been IOS (which is all three of MachO, Darwin and IOS) it's worked out OK so far. But we'd like to support embedded targets under the "*-*-none-macho" triple, which means everything starts falling apart and inconsistent behaviours emerge. This patch should pick a reasonably sensible set of behaviours for the new triple (and any others that come along, with luck). Some choices were debatable (notably FP == r7 or r11), but we can revisit those later when deficiencies become apparent. llvm-svn: 198617
* Make the ARM ABI selectable via SubtargetFeature.Rafael Espindola2014-01-021-12/+16
| | | | | | | This patch makes it possible to select the ABI with -mattr. It will be used to forward clang's -target-abi option to llvm's CodeGen. llvm-svn: 198304
* Recognize EABIHF as environment and use it for RTAPI + VFP.Joerg Sonnenberger2013-12-161-0/+1
| | | | llvm-svn: 197405
* Fix Android regression in r197332.Evgeniy Stepanov2013-12-161-0/+1
| | | | llvm-svn: 197366
* Replace string matching with a switch on Triple::getEnvironment.Joerg Sonnenberger2013-12-151-4/+10
| | | | llvm-svn: 197332
* Enabling thumb2 mode used to force support for armv6t2. Replace thisJoerg Sonnenberger2013-12-131-4/+3
| | | | | | with a temporary assertion and adjust the various test cases. llvm-svn: 197224
* ARM: decide whether to use movw/movt based on "minsize" attribute.Tim Northover2013-12-021-0/+4
| | | | llvm-svn: 196102
* Enable generating legacy IT block for AArch32Weiming Zhao2013-11-131-0/+29
| | | | | | | | | | | | | | By default, the behavior of IT block generation will be determinated dynamically base on the arch (armv8 vs armv7). This patch adds backend options: -arm-restrict-it and -arm-no-restrict-it. The former one restricts the generation of IT blocks (the same behavior as thumbv8) for both arches. The later one allows the generation of legacy IT block (the same behavior as ARMv7 Thumb2) for both arches. Clang will support -mrestrict-it and -mno-restrict-it, which is compatible with GCC. llvm-svn: 194592
* Enable optimization of sin / cos pair into call to __sincos_stret for iOS7+.Bob Wilson2013-11-031-0/+5
| | | | | | | rdar://12856873 Patch by Evan Cheng, with a fix for rdar://13209539 by Tilmann Scheller llvm-svn: 193942
* [ARM] Add Virtualization subtarget feature and more build attributes in this ↵Bradley Smith2013-11-011-0/+1
| | | | | | | | | | | | | | | area Add a Virtualization ARM subtarget feature along with adding proper build attribute emission for Tag_Virtualization_use (encodes Virtualization and TrustZone) and Tag_MPextension_use. Also rework test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll testcase to something that is more maintainable. This changes the focus of this testcase away from testing CPU defaults (which is tested elsewhere), onto specifically testing that attributes are encoded correctly. llvm-svn: 193859
* [ARM] Make sure HasCRC is initialized to false in Subtarget.Amara Emerson2013-10-291-0/+1
| | | | llvm-svn: 193624
* [ARM] Improve build attributes emission.Amara Emerson2013-10-071-1/+2
| | | | llvm-svn: 192111
* CriticalAntiDepBreaker is no longer needed for armv7 scheduling.Andrew Trick2013-09-251-3/+1
| | | | | | | | | | | | | | | | | This is being disabled because it is no longer needed for performance. It is only used by postRAscheduler which is also planned for removal, and it is implemented with an out-dated view of register liveness. It consideres aliases instead of register units, assumes valid kill flags, and assumes implicit uses on partial register defs. Kill flags and implicit operands are error prone and impossible to verify. We should gradually eliminate dependence on them in the postRA phases. Targets that still benefit from this should move to the MI scheduler. If that doesn't solve the problem, then we should add a hook to regalloc to optimize reload placement. llvm-svn: 191348
* [ARM] Split A/R class into separate subtarget features.Amara Emerson2013-09-231-1/+1
| | | | | | Patch by Bradley Smith. llvm-svn: 191202
* [ARMv8] Add support for the v8 cryptography extensions.Amara Emerson2013-09-191-0/+1
| | | | llvm-svn: 190996
* [ARMv8] Change hasV8Fp to hasFPARMv8, and other command line optionsJoey Gouly2013-09-131-1/+1
| | | | | | to be more consistent. llvm-svn: 190692
* ARM: Default to the Swift CPU when targeting armv7s/thumbv7s.Tilmann Scheller2013-09-021-2/+7
| | | | | | | | Test cases adjusted accordingly. This fixes rdar://14871821. llvm-svn: 189766
* Revert 189756 for now, it doesn't match what rdar://14871821 really wants.Tilmann Scheller2013-09-021-7/+2
| | | | | | What we really want is to enable Swift by default for *v7s triples (and there already seems to be some logic which attempts to do that). In that case the iOS version doesn't matter. llvm-svn: 189763
* ARM: Default to Swift when compiling for iOS 6 or later.Tilmann Scheller2013-09-021-2/+7
| | | | | | | | Test cases adjusted accordingly. This fixes rdar://14871821. llvm-svn: 189756
* make arm-use-movt available for all ARMRenato Golin2013-08-151-3/+3
| | | | | | | | | | | | | Before this patch this flag is IOS specific, but is also useful for bare project like bootloaders / kernels etc, since movw / movt prevents simple relocation. Therefore make this flag more commonly available. note: this patch depends on a similiar rename in clang Patch by Jeroen Hofstee. llvm-svn: 188487
* make arm-reserve-r9 available for all ARMRenato Golin2013-08-151-2/+3
| | | | | | | | | | | r9 is defined as a platform-specific register in the ARM EABI. It can be reserved for a special purpose or be used as a general purpose register. Add support for reserving r9 for all ARM, while leaving the IOS usage unchanged. Patch by Jeroen Hofstee. llvm-svn: 188485
* Add a Subtarget feature 'v8fp' to the ARM backend.Joey Gouly2013-06-271-0/+1
| | | | llvm-svn: 185073
* Add a subtarget feature 'v8' to the ARM backend.Joey Gouly2013-06-261-0/+1
| | | | | | This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
* ARM: Add Performance Monitor Extensions featureTim Northover2013-05-231-0/+1
| | | | | | | | | | Performance monitors, including a basic cycle counter, are an official extension in the ARMv7 specification. This adds support for enabling and disabling them, orthogonally from CPU selection. rdar://problem/13939186 llvm-svn: 182602
* Support unaligned load/store on more ARM targetsJF Bastien2013-05-171-7/+44
| | | | | | | | | | | | | | | | | | | | | This patch matches GCC behavior: the code used to only allow unaligned load/store on ARM for v6+ Darwin, it will now allow unaligned load/store for v6+ Darwin as well as for v7+ on Linux and NaCl. The distinction is made because v6 doesn't guarantee support (but LLVM assumes that Apple controls hardware+kernel and therefore have conformant v6 CPUs), whereas v7 does provide this guarantee (and Linux/NaCl behave sanely). The patch keeps the -arm-strict-align command line option, and adds -arm-no-strict-align. They behave similarly to GCC's -mstrict-align and -mnostrict-align. I originally encountered this discrepancy in FastIsel tests which expect unaligned load/store generation. Overall this should slightly improve performance in most cases because of reduced I$ pressure. llvm-svn: 182175
* Revert "Support unaligned load/store on more ARM targets"Derek Schuff2013-05-151-17/+4
| | | | | | This reverts r181898. llvm-svn: 181944
* Support unaligned load/store on more ARM targetsDerek Schuff2013-05-151-4/+17
| | | | | | | | | | | | | | | | | This patch matches GCC behavior: the code used to only allow unaligned load/store on ARM for v6+ Darwin, it will now allow unaligned load/store for v6+ Darwin as well as for v7+ on other targets. The distinction is made because v6 doesn't guarantee support (but LLVM assumes that Apple controls hardware+kernel and therefore have conformant v6 CPUs), whereas v7 does provide this guarantee (and Linux behaves sanely). Overall this should slightly improve performance in most cases because of reduced I$ pressure. Patch by JF Bastien llvm-svn: 181897
* ARM: Make "SMC" instructions conditional on new TrustZone architecture feature.Tim Northover2013-04-101-0/+1
| | | | | | | | | | | | These instructions aren't universally available, but depend on a specific extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new feature is appropriate. This also enables the feature by default on A-class cores which usually have these extensions, to avoid breaking existing code and act as a sensible default. llvm-svn: 179171
* Avoid NEON SP-FP unless unsafe-math or DarwinRenato Golin2013-03-211-1/+10
| | | | | | | | | | NEON is not IEEE 754 compliant, so we should avoid lowering single-precision floating point operations with NEON unless unsafe-math is turned on. The equivalent VFP instructions are IEEE 754 compliant, but in some cores they're much slower, so some archs/OSs might still request it to be on by default, such as Swift and Darwin. llvm-svn: 177651
* Reinitialize the ivars in the subtarget so that they can be reset with the ↵Bill Wendling2013-02-161-39/+45
| | | | | | new features. llvm-svn: 175336
* Temporary revert of 175320.Bill Wendling2013-02-151-45/+39
| | | | llvm-svn: 175322
* Reinitialize the ivars in the subtarget.Bill Wendling2013-02-151-39/+45
| | | | | | | When we're recalculating the feature set of the subtarget, we need to have the ivars in their initial state. llvm-svn: 175320
* Support changing the subtarget features in ARM.Bill Wendling2013-02-151-4/+25
| | | | llvm-svn: 175315
* Add a special ARM trap encoding for NaCl.Eli Bendersky2013-01-301-0/+1
| | | | | | | | More details in this thread: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130128/163783.html Patch by JF Bastien llvm-svn: 173943
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* On some ARM cpus, flags setting movs with shifter operand, i.e. lsl, lsr, asr,Evan Cheng2012-12-201-0/+1
| | | | | | | | | are more expensive than the non-flag setting variant. Teach thumb2 size reduction pass to avoid generating them unless we are optimizing for size. rdar://12892707 llvm-svn: 170728
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-2/+2
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Add LLVM support for Swift.Bob Wilson2012-09-291-0/+6
| | | | llvm-svn: 164899
* TableGen subtarget emitter. Initialize MCSubtargetInfo with the new machine ↵Andrew Trick2012-09-181-1/+2
| | | | | | model. llvm-svn: 164092
OpenPOWER on IntegriCloud