summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MC] Pass MCSubtargetInfo to fixupNeedsRelaxation and applyFixupPeter Smith2018-06-061-16/+25
| | | | | | | | | | | | | | | | | | On targets like Arm some relaxations may only be performed when certain architectural features are available. As functions can be compiled with differing levels of architectural support we must make a judgement on whether we can relax based on the MCSubtargetInfo for the function. This change passes through the MCSubtargetInfo for the function to fixupNeedsRelaxation so that the decision on whether to relax can be made per function. In this patch, only the ARM backend makes use of this information. We must also pass the MCSubtargetInfo to applyFixup because some fixups skip error checking on the assumption that relaxation has occurred, to prevent code-generation errors applyFixup must see the same MCSubtargetInfo as fixupNeedsRelaxation. Differential Revision: https://reviews.llvm.org/D44928 llvm-svn: 334078
* [MC][ARM] Add range checking for Thumb2 resolved fixups.Peter Smith2018-06-051-0/+10
| | | | | | | | | | | | When the branch target of a Thumb2 unconditional or conditonal branch is resolved at assembly time, no range checking is performed on the result leading to incorrect immediates. This change adds a range check: +- 16 Megabytes for unconditional branches, +- 1 Megabyte for the conditional branch. Differential Revision: https://reviews.llvm.org/D46306 llvm-svn: 333997
* [MC][ARM] Correct Thumb BL instruction rangePeter Smith2018-06-051-3/+5
| | | | | | | | | | | | The Thumb BL range is + or - either 16 Megabytes or 4 Megabytes depending on whether the CPU supports Thumb2 or the v8-m baseline ops. The existing check for BL range is incorrectly set at +- 32 Megabytes. This change corrects the higher range and uses the lower range if the featurebits don't have the necessary support for it. Differential Revision: https://reviews.llvm.org/D46305 llvm-svn: 333991
* MC: Change MCAsmBackend::writeNopData() to take a raw_ostream instead of an ↵Peter Collingbourne2018-05-211-25/+26
| | | | | | | | | | | | | MCObjectWriter. NFCI. To make this work I needed to add an endianness field to MCAsmBackend so that writeNopData() implementations know which endianness to use. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47035 llvm-svn: 332857
* ARM: Remove unnecessary argument. NFCI.Peter Collingbourne2018-05-161-4/+2
| | | | | | IsLittleEndian is already a field of ARMAsmBackend. llvm-svn: 332420
* ARM: Deduplicate code and remove unnecessary declaration. NFCI.Peter Collingbourne2018-05-161-19/+5
| | | | llvm-svn: 332419
* Fix a bunch of places where operator-> was used directly on the return from ↵Craig Topper2018-05-051-1/+1
| | | | | | | | | | dyn_cast. Inspired by r331508, I did a grep and found these. Mostly just change from dyn_cast to cast. Some cases also showed a dyn_cast result being converted to bool, so those I changed to isa. llvm-svn: 331577
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-1/+1
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [NFC] fix trivial typos in comments and error messageHiroshi Inoue2018-04-091-1/+1
| | | | | | "is is" -> "is", "are are" -> "are" llvm-svn: 329546
* [ARM][NFC] Avoid recreating MCSubtargetInfo in ARMAsmBackendAlex Bradbury2018-01-031-20/+17
| | | | | | | | | | | | | After D41349, we can now directly access MCSubtargetInfo from createARM*AsmBackend. This patch makes use of this, avoiding the need to create a fresh MCSubtargetInfo (which was previously always done with a blank CPU and feature string). Given the total size of the change remains pretty tiny and we're removing the old explicit destructor, I changed the STI field to a reference rather than a pointer. Differential Revision: https://reviews.llvm.org/D41693 llvm-svn: 321707
* Thread MCSubtargetInfo through Target::createMCAsmBackendAlex Bradbury2018-01-031-8/+12
| | | | | | | | | | | | | | | | | | | | | Currently it's not possible to access MCSubtargetInfo from a TgtMCAsmBackend. D20830 threaded an MCSubtargetInfo reference through MCAsmBackend::relaxInstruction, but this isn't the only function that would benefit from access. This patch removes the Triple and CPUString arguments from createMCAsmBackend and replaces them with MCSubtargetInfo. This patch just changes the interface without making any intentional functional changes. Once in, several cleanups are possible: * Get rid of the awkward MCSubtargetInfo handling in ARMAsmBackend * Support 16-bit instructions when valid in MipsAsmBackend::writeNopData * Get rid of the CPU string parsing in X86AsmBackend and just use a SubtargetFeature for HasNopl * Emit 16-bit nops in RISCVAsmBackend::writeNopData if the compressed instruction set extension is enabled (see D41221) This change initially exposed PR35686, which has since been resolved in r321026. Differential Revision: https://reviews.llvm.org/D41349 llvm-svn: 321692
* Remove redundant includes from lib/Target/ARM.Michael Zolotukhin2017-12-131-2/+0
| | | | llvm-svn: 320635
* [TargetParser] Use enum classes for various ARM kind enums.Florian Hahn2017-07-271-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Using c++11 enum classes ensures that only valid enum values are used for ArchKind, ProfileKind, VersionKind and ISAKind. This removes the need for checks that the provided values map to a proper enum value, allows us to get rid of AK_LAST and prevents comparing values from different enums. It also removes a bunch of static_cast from unsigned to enum values and vice versa, at the cost of introducing static casts to access AArch64ARCHNames and ARMARCHNames by ArchKind. FPUKind and ArchExtKind are the only remaining old-style enum in TargetParser.h. I think it's beneficial to keep ArchExtKind as old-style enum, but FPUKind can be converted too, but this patch is quite big, so could do this in a follow-up patch. I could also split this patch up a bit, if people would prefer that. Reviewers: rengolin, javed.absar, chandlerc, rovka Reviewed By: rovka Subscribers: aemerson, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D35882 llvm-svn: 309287
* Fully fix the movw/movt addend.Rafael Espindola2017-07-111-8/+7
| | | | | | | | | | The issue is not if the value is pcrel. It is whether we have a relocation or not. If we have a relocation, the static linker will select the upper bits. If we don't have a relocation, we have to do it. llvm-svn: 307730
* [ARM, ELF] Don't shift movt relocation offsetsMartin Storsjo2017-07-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For ELF, a movw+movt pair is handled as two separate relocations. If an offset should be applied to the symbol address, this offset is stored as an immediate in the instruction (as opposed to stored as an offset in the relocation itself). Even though the actual value stored in the movt immediate after linking is the top half of the value, we need to store the unshifted offset prior to linking. When the relocation is made during linking, the offset gets added to the target symbol value, and the upper half of the value is stored in the instruction. This makes sure that movw+movt with offset symbols get properly handled, in case the offset addition in the lower half should be carried over to the upper half. This makes the output from the additions to the test case match the output from GNU binutils. For COFF and MachO, the movw/movt relocations are handled as a pair, and the overflow from the lower half gets carried over to the movt, so they should keep the shifted offset just as before. Differential Revision: https://reviews.llvm.org/D35242 llvm-svn: 307713
* Rename and adjust processFixupValue.Rafael Espindola2017-06-301-8/+9
| | | | | | | It was not processing any value. All that it ever did was force relocations, so name it shouldForceRelocation. llvm-svn: 306906
* Simplify the processFixupValue interface. NFC.Rafael Espindola2017-06-241-4/+1
| | | | llvm-svn: 306202
* Remove redundant argument.Rafael Espindola2017-06-241-1/+2
| | | | llvm-svn: 306189
* ARM: move some logic from processFixupValue to applyFixup.Rafael Espindola2017-06-231-21/+31
| | | | | | | | | | | | processFixupValue is called on every relaxation iteration. applyFixup is only called once at the very end. applyFixup is then the correct place to do last minute changes and value checks. While here, do proper range checks again for fixup_arm_thumb_bl. We used to do it, but dropped because of thumb2. We now do it again, but use the thumb2 range. llvm-svn: 306177
* [ARM] Create relocations for beq.w branches to ARM function syms.Florian Hahn2017-06-221-0/+1
| | | | | | | | | | | | | | | | | | Summary: The ARM ELF ABI requires the linker to do interworking for wide conditional branches from Thumb code to ARM code. That was pointed out by @peter.smith in the comments for D33436. Reviewers: rafael, peter.smith, echristo Reviewed By: peter.smith Subscribers: aemerson, javed.absar, kristof.beyls, llvm-commits, peter.smith Differential Revision: https://reviews.llvm.org/D34447 llvm-svn: 306009
* Use a MutableArrayRef. NFC.Rafael Espindola2017-06-211-4/+4
| | | | llvm-svn: 305968
* [ARM] Use FixupKind variable in processFixupValue (cleanup, NFC).Florian Hahn2017-06-071-10/+10
| | | | llvm-svn: 304905
* [ARM] Create relocations for unconditional branches.Florian Hahn2017-06-071-7/+12
| | | | | | | | | | | | | | | | | | | Summary: Relocations are required for unconditional branches to function symbols with different execution mode. Without this patch, incorrect branches are generated for tail calls between functions with different execution mode. Reviewers: peter.smith, rafael, echristo, kristof.beyls Reviewed By: peter.smith Subscribers: aemerson, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D33898 llvm-svn: 304882
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-2/+2
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ARM] Add curly braces around switch case [NFC] Peter Smith2017-06-061-1/+2
| | | | | | | | | | | | | My previous commit r304702 introduced a new case into a switch statement. This case defined a variable but I forgot to add the curly brackets around the case to limit the scope. This change puts the curly braces back in so that the next person that adds a case doesn't get a build failure. Thanks to avieira for the spot. Differential Revision: https://reviews.llvm.org/D33931 llvm-svn: 304785
* [ARM] Support fixup for Thumb2 modified immediatePeter Smith2017-06-051-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds a new fixup fixup_t2_so_imm for the t2_so_imm_asmoperand "T2SOImm". The fixup permits code such as: .L1: sub r3, r3, #.L2 - .L1 .L2: to assemble in Thumb2 as well as in ARM state. The operand predicate isT2SOImm() explicitly doesn't match expressions containing :upper16: and :lower16: as expressions with these operators must match the movt and movw instructions. The test mov r0, foo2 in thumb2-diagnostics is moved to a new file as the fixup delays the error message till after the assembler has quit due to the other errors. As the mov instruction shares the t2_so_imm_asmoperand mov instructions with a non constant expression now match t2MOVi rather than t2MOVi16 so the error message is slightly different. Fixes PR28647 Differential Revision: https://reviews.llvm.org/D33492 llvm-svn: 304702
* [ARM] Create relocations for Thumb functions calling ARM fns in ELF.Florian Hahn2017-06-011-0/+9
| | | | | | | | | | | | | | | | Summary: Without using a fixup in this case, BL will be used instead of BLX to call internal ARM functions from Thumb functions. Reviewers: rafael, t.p.northover, peter.smith, kristof.beyls Reviewed By: peter.smith Subscribers: srhines, echristo, aemerson, rengolin, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D33436 llvm-svn: 304413
* Add MCContext argument to MCAsmBackend::applyFixup for error reportingAlex Bradbury2017-04-051-37/+30
| | | | | | | | | | | | | | | | A number of backends (AArch64, MIPS, ARM) have been using MCContext::reportError to report issues such as out-of-range fixup values in their TgtAsmBackend. This is great, but because MCContext couldn't easily be threaded through to the adjustFixupValue helper function from its usual callsite (applyFixup), these backends ended up adding an MCContext* argument and adding another call to applyFixup to processFixupValue. Adding an MCContext parameter to applyFixup makes this unnecessary, and even better - applyFixup can take a reference to MCContext rather than a potentially null pointer. Differential Revision: https://reviews.llvm.org/D30264 llvm-svn: 299529
* Fix typo in commentArtyom Skrobov2017-03-141-1/+1
| | | | llvm-svn: 297742
* [Assembler] Fix crash when assembling .quad for AArch32.Chad Rosier2017-01-181-1/+2
| | | | | | | | | | | A 64-bit relocation does not exist in 32-bit ARMELF. Report an error instead of crashing. PR23870 Patch by Sanne Wouda (sanwou01). Differential Revision: https://reviews.llvm.org/D28851 llvm-svn: 292373
* ARM: by default don't set the Thumb bit on MachO relocated values.Tim Northover2016-08-251-10/+11
| | | | | | | | | | | | | Its existence is largely historical, apparently we tried to make ARM object files look maybe-almost-possibly runnable by putting our best guess at the actual value into relocated locations. Of course, the real linker then comes along and can completely change things. But it should only be there for word-sized and movw/movt relocations. It can't be encoded in branch relocations, and I've seen it mess up validity calculations twice in the last couple of weeks so the default is clearly problematic. llvm-svn: 279773
* ARM: don't diagnose cbz/cbnz to Thumb functions.Tim Northover2016-08-241-1/+2
| | | | | | | | A branch-distance to a Thumb function shouldn't be forced to be odd for CBZ/CBNZ instructions because (assuming it's within range), it's going to be a valid, even offset. llvm-svn: 279665
* Replace a few more "fall through" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-2/+2
| | | | | | Follow up to r278902. I had missed "fall through", with a space. llvm-svn: 278970
* Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-3/+3
| | | | | | | This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
* Correct the upper bound for a CBZ/CBNZ branch target.Prakhar Bahuguna2016-08-161-2/+4
| | | | | | | | | | | | | Summary: Fix for the upper bound check that was causing a build failure. Reviewers: olista01, rengolin, t.p.northover Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D23501 llvm-svn: 278789
* [Thumb] Validate branch target for CBZ/CBNZ instructions.Prakhar Bahuguna2016-08-161-0/+5
| | | | | | | | | | | | | | | | | Summary: The assembler currently does not check the branch target for CBZ/CBNZ instructions, which only permit branching forwards with a positive offset. This adds validation for the branch target to ensure negative PC-relative offsets are not encoded into the instruction, whether specified as a literal or as an assembler symbol. Reviewers: rengolin, t.p.northover Subscribers: llvm-commits, rengolin Differential Revision: https://reviews.llvm.org/D23312 llvm-svn: 278788
* Revert "[Thumb] Validate branch target for CBZ/CBNZ instructions."Matthias Braun2016-08-151-5/+0
| | | | | | | | | | | This currently breaks the greendragon clang-stage1-configure-RA/ and brotli. It is probably just uncovering a pre-existing problem. Reverting temporarily to get the buildbots green again. A reduced testcase will follow shortly. This reverts commit r278659. llvm-svn: 278711
* [Thumb] Validate branch target for CBZ/CBNZ instructions.Prakhar Bahuguna2016-08-151-0/+5
| | | | | | | | | | | | | | | | | Summary: The assembler currently does not check the branch target for CBZ/CBNZ instructions, which only permit branching forwards with a positive offset. This adds validation for the branch target to ensure negative PC-relative offsets are not encoded into the instruction, whether specified as a literal or as an assembler symbol. Reviewers: rengolin, t.p.northover Subscribers: llvm-commits, rengolin Differential Revision: https://reviews.llvm.org/D23312 llvm-svn: 278659
* MC] Provide an MCTargetOptions to implementors of MCAsmBackendCtorTy, NFCJoel Jones2016-07-251-8/+13
| | | | | | | | | | | | | | | Some targets, notably AArch64 for ILP32, have different relocation encodings based upon the ABI. This is an enabling change, so a future patch can use the ABIName from MCTargetOptions to chose which relocations to use. Tested using check-llvm. The corresponding change to clang is in: http://reviews.llvm.org/D16538 Patch by: Joel Jones Differential Revision: https://reviews.llvm.org/D16213 llvm-svn: 276654
* Fix branch relaxation in 16-bit mode.Nirav Dave2016-07-111-1/+3
| | | | | | | | | | | | | | | Thread through MCSubtargetInfo to relaxInstruction function allowing relaxation to generate jumps with 16-bit sized immediates in 16-bit mode. This fixes PR22097. Reviewers: dwmw2, tstellarAMD, craig.topper, jyknight Subscribers: jfb, arsenm, jyknight, llvm-commits, dsanders Differential Revision: http://reviews.llvm.org/D20830 llvm-svn: 275068
* ARM: report an error when attempting to target a misalgined BLXTim Northover2016-05-101-3/+12
| | | | | | | The CodeGen problem was fixed in r269101, but we still miscompiled assembly that tried the same thing. llvm-svn: 269126
* Fix for pr24346: arm asm label calculation error in subJames Molloy2016-04-011-0/+11
| | | | | | | | | | | | | | | | | | | | | | Some ARM instructions encode 32-bit immediates as a 8-bit integer (0-255) and a 4-bit rotation (0-30, even) in its least significant 12 bits. The original fixup, FK_Data_4, patches the instruction by the value bit-to-bit, regardless of the encoding. For example, assuming the label L1 and L2 are 0x0 and 0x104 respectively, the following instruction: add r0, r0, #(L2 - L1) ; expects 0x104, i.e., 260 would be assembled to the following, which adds 1 to r0, instead of 260: e2800104 add r0, r0, #4, 2 ; equivalently 1 The new fixup kind fixup_arm_mod_imm takes care of the encoding: e2800f41 add r0, r0, #260 Patch by Ting-Yuan Huang! llvm-svn: 265122
* [MC] Rename TLSCALL as it's not ARM specific.Davide Italiano2016-03-151-2/+2
| | | | | | | | | | | | | | `MCSymbolRefExpr` variant kind for TLSCALL is prefixed with _ARM_ since this is how it was originally implemented. The X86_64 version is exactly the same so there's no reason to create a new variant, we can just rename the existing one to be machine-independent. This generalization is the first step to implement support for GNU2 TLS dialect in MC. Differential Revision: http://reviews.llvm.org/D18160 llvm-svn: 263515
* Don't put classes in headers into anonymous namespaces.Benjamin Kramer2016-01-271-1/+1
| | | | | | You want ODR violations? That's how you get ODR violations. llvm-svn: 258973
* [ARM] Add ARMv8.2-A FP16 scalar instructionsOliver Stannard2016-01-251-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was originally committed as r255762, but reverted as it broke windows bots. Re-commitiing the exact same patch, as the underlying cause was fixed by r258677. ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 258678
* [ARM] Add B.W and CBZ instructions to ARMv8-M BaselineBradley Smith2016-01-151-2/+4
| | | | llvm-svn: 257881
* Revert "[ARM] Add ARMv8.2-A FP16 scalar instructions"Reid Kleckner2015-12-161-41/+0
| | | | | | This reverts commit r255762. llvm-svn: 255806
* [ARM] Add ARMv8.2-A FP16 scalar instructionsOliver Stannard2015-12-161-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | ARMv8.2-A adds 16-bit floating point versions of all existing VFP floating-point instructions. This is an optional extension, so all of these instructions require the FeatureFullFP16 subtarget feature. The assembly for these instructions uses S registers (AArch32 does not have H registers), but the instructions have ".f16" type specifiers rather than ".f32" or ".f64". The top 16 bits of each source register are ignored, and the top 16 bits of the destination register are set to zero. These instructions are mostly the same as the 32- and 64-bit versions, but they use coprocessor 9 rather than 10 and 11. Two new instructions, VMOVX and VINS, have been added to allow packing and extracting two 16-bit floats stored in the top and bottom halves of an S register. New fixup kinds have been added for the PC-relative load and store instructions, but no ELF relocations have been added as they have a range of 512 bytes. Differential Revision: http://reviews.llvm.org/D15038 llvm-svn: 255762
* [Assembler] Make fatal assembler errors non-fatalOliver Stannard2015-11-171-14/+28
| | | | | | | | | | | | | | Currently, if the assembler encounters an error after parsing (such as an out-of-range fixup), it reports this as a fatal error, and so stops after the first error. However, for most of these there is an obvious way to recover after emitting the error, such as emitting the fixup with a value of zero. This means that we can report on all of the errors in a file, not just the first one. MCContext::reportError records the fact that an error was encountered, so we won't actually emit an object file with the incorrect contents. Differential Revision: http://reviews.llvm.org/D14717 llvm-svn: 253328
OpenPOWER on IntegriCloud