summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/ARMMCInstLower.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [CodeGen] Add begin-end iterators to MachineInstrJaved Absar2017-07-171-3/+1
| | | | | | | | | Convert iteration over operands to range-loop. Reviewed by: @rovka, @echristo Differential Revision: https://reviews.llvm.org/D35419 llvm-svn: 308173
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Re-commit r301040 "X86: Don't emit zero-byte functions on Windows"Hans Wennborg2017-04-211-3/+1
| | | | | | | | | In addition to the original commit, tighten the condition for when to pad empty functions to COFF Windows. This avoids running into problems when targeting e.g. Win32 AMDGPU, which caused test failures when this was committed initially. llvm-svn: 301047
* Revert r301040 "X86: Don't emit zero-byte functions on Windows"Hans Wennborg2017-04-211-1/+3
| | | | | | This broke almost all bots. Reverting while fixing. llvm-svn: 301041
* X86: Don't emit zero-byte functions on WindowsHans Wennborg2017-04-211-3/+1
| | | | | | | | | | | | | | | | | | Empty functions can lead to duplicate entries in the Guard CF Function Table of a binary due to multiple functions sharing the same RVA, causing the kernel to refuse to load that binary. We had a terrific bug due to this in Chromium. It turns out we were already doing this for Mach-O in certain situations. This patch expands the code for that in AsmPrinter::EmitFunctionBody() and renames TargetInstrInfo::getNoopForMachoTarget() to simply getNoop() since it seems it was used for not just Mach-O anyway. Differential Revision: https://reviews.llvm.org/D32330 llvm-svn: 301040
* [ARM] Make RWPI use movw/movt when availableChristof Douma2017-02-071-3/+7
| | | | | | | | | | | | | | | | | When constructing global address literals while targeting the RWPI relocation model. LLVM currently only uses literal pools. If MOVW/MOVT instructions are available we can use these instead. Beside being more efficient it allows -arm-execute-only to work with -relocation-model=RWPI as well. When we generate MOVW/MOVT for global addresses when targeting the RWPI relocation model, we need to use base relative relocations. This patch does the needed plumbing in MC to generate these for MOVW/MOVT. Differential Revision: https://reviews.llvm.org/D29487 Change-Id: I446786e43a6f5aa9b6a5bb2cd216d60d41c7755d llvm-svn: 294298
* [ARM] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-01-261-4/+12
| | | | | | minor fixes (NFC). llvm-svn: 293229
* [XRay] Merge instrumentation point table emission code into AsmPrinter.Dean Michael Berris2017-01-031-38/+0
| | | | | | | | | | | | | | | | | | Summary: No need to have this per-architecture. While there, unify 32-bit ARM's behaviour with what changed elsewhere and start function names lowercase as per the coding standards. Individual entry emission code goes to the entry's own class. Fully tested on amd64, cross-builds on both ARMs and PowerPC. Reviewers: dberris Subscribers: aemerson, llvm-commits Differential Revision: https://reviews.llvm.org/D28209 llvm-svn: 290858
* [ARM] Implement execute-only support in CodeGenPrakhar Bahuguna2016-12-151-0/+2
| | | | | | | | | | | | | | | | | | | | This implements execute-only support for ARM code generation, which prevents the compiler from generating data accesses to code sections. The following changes are involved: * Add the CodeGen option "-arm-execute-only" to the ARM code generator. * Add the clang flag "-mexecute-only" as well as the GCC-compatible alias "-mpure-code" to enable this option. * When enabled, literal pools are replaced with MOVW/MOVT instructions, with VMOV used in addition for floating-point literals. As the MOVT instruction is required, execute-only support is only available in Thumb mode for targets supporting ARMv8-M baseline or Thumb2. * Jump tables are placed in data sections when in execute-only mode. * The execute-only text section is assigned section ID 0, and is marked as unreadable with the SHF_ARM_PURECODE flag with symbol 'y'. This also overrides selection of ELF sections for globals. llvm-svn: 289784
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-1/+1
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* [xray] Add XRay support for Mach-O in CodeGenKuba Mracek2016-11-231-17/+27
| | | | | | | | Currently, XRay only supports emitting the XRay table (xray_instr_map) on ELF binaries. Let's add Mach-O support. Differential Revision: https://reviews.llvm.org/D26983 llvm-svn: 287734
* [XRay] Support for for tail calls for ARM no-ThumbDean Michael Berris2016-10-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds simplified support for tail calls on ARM with XRay instrumentation. Known issue: compiled with generic flags: `-O3 -g -fxray-instrument -Wall -std=c++14 -ffunction-sections -fdata-sections` (this list doesn't include my specific flags like --target=armv7-linux-gnueabihf etc.), the following program #include <cstdio> #include <cassert> #include <xray/xray_interface.h> [[clang::xray_always_instrument]] void __attribute__ ((noinline)) fC() { std::printf("In fC()\n"); } [[clang::xray_always_instrument]] void __attribute__ ((noinline)) fB() { std::printf("In fB()\n"); fC(); } [[clang::xray_always_instrument]] void __attribute__ ((noinline)) fA() { std::printf("In fA()\n"); fB(); } // Avoid infinite recursion in case the logging function is instrumented (so calls logging // function again). [[clang::xray_never_instrument]] void simplyPrint(int32_t functionId, XRayEntryType xret) { printf("XRay: functionId=%d type=%d.\n", int(functionId), int(xret)); } int main(int argc, char* argv[]) { __xray_set_handler(simplyPrint); printf("Patching...\n"); __xray_patch(); fA(); printf("Unpatching...\n"); __xray_unpatch(); fA(); return 0; } gives the following output: Patching... XRay: functionId=3 type=0. In fA() XRay: functionId=3 type=1. XRay: functionId=2 type=0. In fB() XRay: functionId=2 type=1. XRay: functionId=1 type=0. XRay: functionId=1 type=1. In fC() Unpatching... In fA() In fB() In fC() So for function fC() the exit sled seems to be called too much before function exit: before printing In fC(). Debugging shows that the above happens because printf from fC is also called as a tail call. So first the exit sled of fC is executed, and only then printf is jumped into. So it seems we can't do anything about this with the current approach (i.e. within the simplification described in https://reviews.llvm.org/D23988 ). Differential Revision: https://reviews.llvm.org/D25030 llvm-svn: 284456
* [XRay] ARM 32-bit no-Thumb support in LLVMDean Michael Berris2016-09-191-0/+94
| | | | | | | | | | | | This is a port of XRay to ARM 32-bit, without Thumb support yet. The XRay instrumentation support is moving up to AsmPrinter. This is one of 3 commits to different repositories of XRay ARM port. The other 2 are: https://reviews.llvm.org/D23932 (Clang test) https://reviews.llvm.org/D23933 (compiler-rt) Differential Revision: https://reviews.llvm.org/D23931 llvm-svn: 281878
* Revert "[XRay] ARM 32-bit no-Thumb support in LLVM"Renato Golin2016-09-081-87/+0
| | | | | | | | | | And associated commits, as they broke the Thumb bots. This reverts commit r280935. This reverts commit r280891. This reverts commit r280888. llvm-svn: 280967
* [XRay] ARM 32-bit no-Thumb support in LLVMDean Michael Berris2016-09-081-0/+87
| | | | | | | | | | | | This is a port of XRay to ARM 32-bit, without Thumb support yet. The XRay instrumentation support is moving up to AsmPrinter. This is one of 3 commits to different repositories of XRay ARM port. The other 2 are: 1. https://reviews.llvm.org/D23932 (Clang test) 2. https://reviews.llvm.org/D23933 (compiler-rt) Differential Revision: https://reviews.llvm.org/D23931 llvm-svn: 280888
* fix indentationEtienne Bergeron2016-06-211-1/+1
| | | | llvm-svn: 273274
* Removing an unused switch statement that has only a default label. This ↵Aaron Ballman2016-06-201-22/+16
| | | | | | happens to also eliminate an instance of switchception. NFC intended. llvm-svn: 273161
* Don't print (PLT) on arm.Rafael Espindola2016-06-161-5/+0
| | | | | | | | | The R_ARM_PLT32 relocation is deprecated and is not produced by MC. This means that the code being deleted is dead from the .o point of view and was making the .s more confusing. llvm-svn: 272909
* MC: Clean up MCExpr naming. NFC.Jim Grosbach2015-05-301-9/+9
| | | | llvm-svn: 238634
* MC: Modernize MCOperand API naming. NFC.Jim Grosbach2015-05-131-5/+5
| | | | | | MCOperand::Create*() methods renamed to MCOperand::create*(). llvm-svn: 237275
* Add support for ARM modified-immediate assembly syntax.Asiri Rathnayake2014-12-021-1/+35
| | | | | | | | | | | | | | | | | | | | Certain ARM instructions accept 32-bit immediate operands encoded as a 8-bit integer value (0-255) and a 4-bit rotation (0-30, even). Current ARM assembly syntax support in LLVM allows the decoded (32-bit) immediate to be specified as a single immediate operand for such instructions: mov r0, #4278190080 The ARMARM defines an extended assembly syntax allowing the encoding to be made more explicit, as in: mov r0, #255, #8 ; (same 32-bit value as above) The behaviour of the two instructions can be different w.r.t flags, which is documented under "Modified immediate constants" in ARMARM. This patch enables support for this extended syntax at the MC layer. llvm-svn: 223113
* ARM: use symbolic name for constantSaleem Abdulrasool2014-06-301-1/+1
| | | | | | | This just changes the constant value to the symbolic name corresponding to it. NFC. llvm-svn: 212011
* Prune includes in ARM target.Craig Topper2014-03-221-0/+1
| | | | llvm-svn: 204548
* Move the llvm mangler to lib/IR.Rafael Espindola2014-01-071-1/+1
| | | | | | This makes it available to tools that don't link with target (like llvm-ar). llvm-svn: 198708
* Add support for parsing ARM symbol variants on ELF targetsDavid Peixotto2013-12-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ARM symbol variants are written with parens instead of @ like this: .word __GLOBAL_I_a(target1) This commit adds support for parsing these symbol variants in expressions. We introduce a new flag to MCAsmInfo that indicates the parser should use parens to parse the symbol variant. The expression parser is modified to look for symbol variants using parens instead of @ when the corresponding MCAsmInfo flag is true. The MCAsmInfo parens flag is enabled only for ARM on ELF. By adding this flag to MCAsmInfo, we are able to get rid of redundant ARM-specific symbol variants and use the generic variants instead (e.g. VK_GOT instead of VK_ARM_GOT). We use the new UseParensForSymbolVariant attribute in MCAsmInfo to correctly print the symbol variants for arm. To achive this we need to keep a handle to the MCAsmInfo in the MCSymbolRefExpr class that we can check when printing the symbol variant. Updated Tests: Changed case of symbol variant to match the generic kind. test/CodeGen/ARM/tls-models.ll test/CodeGen/ARM/tls1.ll test/CodeGen/ARM/tls2.ll test/CodeGen/Thumb2/tls1.ll test/CodeGen/Thumb2/tls2.ll PR18080 llvm-svn: 196424
* ARM: remove special cases for Darwin dynamic-no-pic mode.Tim Northover2013-11-251-4/+7
| | | | | | | | | These are handled almost identically to static mode (and ELF's global address materialisation), except that a symbol may have "$non_lazy_ptr" appended. This can be handled by passing appropriate flags along with the instruction instead of using entirely separate pseudo-instructions. llvm-svn: 195655
* Add a helper getSymbol to AsmPrinter.Rafael Espindola2013-10-291-1/+1
| | | | llvm-svn: 193627
* 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
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-1/+1
| | | | | | | | | | | | | | | | | 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
* Convert assert(0) to llvm_unreachableCraig Topper2012-02-071-5/+2
| | | | llvm-svn: 149961
* Ignore register mask operands when lowering instructions to MC.Jakob Stoklund Olesen2012-01-181-0/+3
| | | | | | | This is similar to implicit register operands. MC doesn't understand register liveness and call clobbers. llvm-svn: 148437
* Sink ARMMCExpr and ARMAddressingModes into MC layer. First step to separate ↵Evan Cheng2011-07-201-1/+1
| | | | | | ARM MC code from target. llvm-svn: 135636
* Use TableGen'erated pseudo lowering for ARM.Jim Grosbach2011-07-081-54/+64
| | | | | | | | | Hook up the TableGen lowering for simple pseudo instructions for ARM and use it for a subset of the many pseudos the backend has as proof of concept. More conversions to come. llvm-svn: 134705
* Add needed braces.Bill Wendling2011-01-261-1/+2
| | | | llvm-svn: 124273
* Model :upper16: and :lower16: as ARM specific MCTargetExpr. This is a stepEvan Cheng2011-01-131-8/+18
| | | | | | | | in the right direction. It eliminated some hacks and will unblock codegen work. But it's far from being done. It doesn't reject illegal expressions, e.g. (FOO - :lower16:BAR). It also doesn't work in Thumb2 mode at all. llvm-svn: 123369
* Move the ARMAsmPrinter class defintiion into a header file.Jim Grosbach2010-12-011-3/+3
| | | | llvm-svn: 120551
* Trailing whitespace.Jim Grosbach2010-11-301-3/+3
| | | | llvm-svn: 120497
* trim #includes.Chris Lattner2010-11-141-5/+1
| | | | llvm-svn: 119075
* rename LowerToMCInst -> LowerARMMachineInstrToMCInst.Chris Lattner2010-11-141-1/+2
| | | | llvm-svn: 119071
* even more simplifications. ARM MCInstLowering is now justChris Lattner2010-11-141-12/+11
| | | | | | | a single function instead of a class. It doesn't need the complexity that X86 does. llvm-svn: 119070
* more shrinkificationChris Lattner2010-11-141-5/+1
| | | | llvm-svn: 119068
* more simplifications.Chris Lattner2010-11-141-84/+17
| | | | llvm-svn: 119067
* simplify and tidy upChris Lattner2010-11-141-27/+10
| | | | llvm-svn: 119066
* Add support for ELF PLT references for ARM MC asm printing. Adding aJim Grosbach2010-09-221-9/+22
| | | | | | | | new VariantKind to the MCSymbolExpr seems like overkill, but I'm not sure there's a more straightforward way to get the printing difference captured. (i.e., x86 uses @PLT, ARM uses (PLT)). llvm-svn: 114613
* Enable a few additional asserts in MC instruction lowering.Jim Grosbach2010-09-221-9/+6
| | | | llvm-svn: 114601
* Remove a few commented out bitsJim Grosbach2010-09-221-14/+0
| | | | llvm-svn: 114576
* handle the upper16/lower16 target operand flags on symbol references for MCJim Grosbach2010-09-171-5/+35
| | | | | | instruction lowering. llvm-svn: 114191
* Make sure to promote single precision floats to double before extracting themJim Grosbach2010-09-161-2/+4
| | | | | | from the APFloat. llvm-svn: 114096
* store MC FP immediates as a double instead of as an APFloat, thus avoiding anJim Grosbach2010-09-161-1/+2
| | | | | | unnecessary dtor for MCOperand. llvm-svn: 114064
* Add support for floating point immediates to MC instruction printing. ARMJim Grosbach2010-09-151-0/+4
| | | | | | | | | | | VFP instructions use it for loading some constants, so implement that handling. Not thrilled with adding a member to MCOperand, but not sure there's much of a better option that's not pretty fragile (like putting a double in the union instead and just assuming that's good enough). Suggestions welcome... llvm-svn: 113996
OpenPOWER on IntegriCloud