summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/ARM/MCTargetDesc/ARMMCCodeEmitter.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* MC: correct IMAGE_REL_ARM_MOV32T relocation emissionSaleem Abdulrasool2014-05-211-3/+0
| | | | | | | | | | | | This corrects the emission of IMAGE_REL_ARM_MOV32T relocations. Previously, we were avoiding the high portion of the relocation too early. If there was a section-relative relocation with an offset greater than 16-bits (65535), you would end up truncating the high order bits of the offset. Allow the current relocation representation to flow through out the MC layer to the object writer. Use the new ability to restrict recorded relocations to avoid emitting the relocation into the final object. llvm-svn: 209337
* Add WoA object file emission supportSaleem Abdulrasool2014-04-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | Introduce support for WoA PE/COFF object file emission from LLVM. Add the new target specific PE/COFF Streamer (ARMWinCOFFStreamer) that handles the ARM specific behaviour of PE/COFF object emission. ARM exception information is not yet emitted and is a TODO item. The ARM specific object writer (ARMWinCOFFObjectWriter) handles the ARM specific relocation handling in conjunction with the WinCOFFObjectWriter in the MC layer. The MC layer needs to be updated to deal with the relocation adjustments. Branch relocations are adjusted by 4 bytes (unlikely their ELF counterparts). Minor tweaks to switch multiple conditional checks into equivalent switch statements. The ObjectFileInfo is updated to relax the object file setup for Windows COFF. Move the architecture checks into an assertion. Windows COFF is currently only supported on x86, x86_64, and ARM (thumb). Rather than defaulting to ELF, we will refuse to generate an object file. This is better though as you do not get an (arbitrary) object file which is different from the request. llvm-svn: 207345
* [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
* Change the ARM assembler to require a :lower16: or :upper16 on non-constantKevin Enderby2014-04-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | expressions for mov instructions instead of silently truncating by default. For the ARM assembler, we want to avoid misleadingly allowing something like "mov r0, <symbol>" especially when we turn it into a movw and the expression <symbol> does not have a :lower16: or :upper16" as part of the expression. We don't want the behavior of silently truncating, which can be unexpected and lead to bugs that are difficult to find since this is an easy mistake to make. This does change the previous behavior of llvm but actually matches an older gnu assembler that would not allow this but print less useful errors of like “invalid constant (0x927c0) after fixup” and “unsupported relocation on symbol foo”. The error for llvm is "immediate expression for mov requires :lower16: or :upper16" with correct location information on the operand as shown in the added test cases. rdar://12342160 llvm-svn: 206669
* ARM: rename ARMle/ARMbe with ARMLE/ARMBE, and Thumble/Thumbbe with ↵Christian Pirker2014-04-011-2/+2
| | | | | | ThumbLE/ThumbBE llvm-svn: 205317
* Recommitted fix for PR18931, with extended tests set.Stepan Dyatkovskiy2014-03-291-1/+19
| | | | | | | | | | | | | Issue subject: Crash using integrated assembler with immediate arithmetic Fix description: Expressions like 'cmp r0, #(l1 - l2) >> 3' could not be evaluated on asm parsing stage, since it is impossible to resolve labels on this stage. In the end of stage we still have expression (MCExpr). Then, when we want to encode it, we expect it to be an immediate, but it still an expression. Patch introduces a Fixup (MCFixup instance), that is processed after main encoding stage. llvm-svn: 205094
* Completely rewrite ELFObjectWriter::RecordRelocation.Rafael Espindola2014-03-291-37/+6
| | | | | | | | | | | | | | | | | | | I started trying to fix a small issue, but this code has seen a small fix too many. The old code was fairly convoluted. Some of the issues it had: * It failed to check if a symbol difference was in the some section when converting a relocation to pcrel. * It failed to check if the relocation was already pcrel. * The pcrel value computation was wrong in some cases (relocation-pc.s) * It was missing quiet a few cases where it should not convert symbol relocations to section relocations, leaving the backends to patch it up. * It would not propagate the fact that it had changed a relocation to pcrel, requiring a quiet nasty work around in ARM. * It was missing comments. llvm-svn: 205076
* Add ARM big endian Target (armeb, thumbeb)Christian Pirker2014-03-281-9/+17
| | | | | | Reviewed at http://llvm-reviews.chandlerc.com/D3095 llvm-svn: 205007
* Rejected r204899 and r204900 due to remaining test failures on ↵Stepan Dyatkovskiy2014-03-271-17/+1
| | | | | | cmake-llvm-x86_64-linux buildbot. llvm-svn: 204901
* Fix for pr18931: Crash using integrated assembler with immediate arithmeticStepan Dyatkovskiy2014-03-271-1/+17
| | | | | | | | | | | Fix description: Expressions like 'cmp r0, #(l1 - l2) >> 3' could not be evaluated on asm parsing stage, since it is impossible to resolve labels on this stage. In the end of stage we still have expression (MCExpr). Then, when we want to encode it, we expect it to be an immediate, but it still an expression. Patch introduces a Fixup (MCFixup instance), that is processed after main encoding stage. llvm-svn: 204899
* This reverts commit r203762, "ARM: support emission of complex SO expressions".Jiangning Liu2014-03-211-14/+2
| | | | | | The commit r203762 introduced silent failure for complext SO expression, and it's even worse than compiler crash. llvm-svn: 204427
* ARM: ignore unused variable to fix -Wunused-variable buildsSaleem Abdulrasool2014-03-131-0/+1
| | | | llvm-svn: 203765
* ARM: support emission of complex SO expressionsSaleem Abdulrasool2014-03-131-2/+13
| | | | | | | | | | | | | | Support to the IAS was added to actually parse and handle the complex SO expressions. However, the object file lowering was not updated to compensate for the fact that the shift operand may be an absolute expression. When trying to assemble to an object file, the lowering would fail while succeeding when emitting purely assembly. Add an appropriate test. The test case is inspired by the test case provided by Jiangning Liu who also brought the issue to light. llvm-svn: 203762
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-101-1/+1
| | | | | | class. llvm-svn: 203439
* Delete MCSubtargetInfo data members from target MCCodeEmitter classesDavid Woodhouse2014-01-281-28/+25
| | | | | | | | The subtarget info is explicitly passed to the EncodeInstruction method and we should use that subtarget info to influence any encoding decisions. llvm-svn: 200350
* Propagate MCSubtargetInfo through TableGen's getBinaryCodeForInstr()David Woodhouse2014-01-281-136/+250
| | | | llvm-svn: 200349
* Explictly pass MCSubtargetInfo to MCCodeEmitter::EncodeInstruction()David Woodhouse2014-01-281-2/+4
| | | | llvm-svn: 200348
* ARM IAS: support emitting constant values in target expressionsSaleem Abdulrasool2014-01-111-0/+15
| | | | | | | | A 32-bit immediate value can be formed from a constant expression and loaded into a register. Add support to emit this into an object file. Because this value is a constant, a relocation must *not* be produced for it. llvm-svn: 199023
* ARM MachO: sort out isTargetDarwin/isTargetIOS/... checks.Tim Northover2014-01-061-5/+5
| | | | | | | | | | | | | | | | | | 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
* Return early from getUnconditionalBranchTargetOpValue if the branch target isLang Hames2013-10-281-1/+1
| | | | | | | | | | | | | | | | | an MCExpr, in order to avoid writing an encoded zero value in the immediate field. When getUnconditionalBranchTargetOpValue is called with an MCExpr target, we don't know what the final immediate field value should be. We shouldn't explicitly set the immediate field to an encoded zero value as zero is encoded with a non-zero bit pattern. This leads to bits being set that pollute the final immediate value. The nature of the encoding is such that the polluted bits only affect very large immediate values, explaining why this hasn't caused problems earlier. Fixes <rdar://problem/15155975>. llvm-svn: 193535
* Clean up some usage of Triple. The base class has methods for determining ↵Cameron Esfahani2013-08-291-2/+1
| | | | | | if the target is iOS and Linux. llvm-svn: 189604
* Add support for Thumb2 literal loads with negative zero offsetMihai Popa2013-08-161-2/+4
| | | | | | | | Thumb2 literal loads use an offset encoding which allows for negative zero. This fixes parsing and encoding so that #-0 is correctly processed. The parser represents #-0 as INT32_MIN. llvm-svn: 188549
* Fix signed overflow in when computing encodings for ADR instructionsMihai Popa2013-08-131-1/+1
| | | | llvm-svn: 188268
* Fix assembling of Thumb2 branch instructions.Mihai Popa2013-08-091-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The long encoding for Thumb2 unconditional branches is broken. Additionally, there is no range checking for target operands; as such for instructions originating in assembly code, only short Thumb encodings are generated, regardless of the bitsize needed for the offset. Adding range checking is non trivial due to the representation of Thumb branch instructions. There is no true difference between conditional and unconditional branches in terms of operands and syntax - even unconditional branches have a predicate which is expected to match that of the IT block they are in. Yet, the encodings and the permitted size of the offset differ. Due to this, for any mnemonic there are really 4 encodings to choose for. The problem cannot be handled in the parser alone or by manipulating td files. Because the parser builds first a set of match candidates and then checks them one by one, whatever tablegen-only solution might be found will ultimately be dependent of the parser's evaluation order. What's worse is that due to the fact that all branches have the same syntax and the same kinds of operands, that order is governed by the lexicographical ordering of the names of operand classes... To circumvent all this, any necessary disambiguation is added to the instruction validation pass. llvm-svn: 188067
* [ARMv8] Add support for the NEON instructions vmaxnm/vminnm.Joey Gouly2013-07-171-0/+13
| | | | | | | This adds a new class for non-predicable NEON instructions and a new DecoderNamespace for v8 NEON instructions. llvm-svn: 186504
* ARM: fix literal load with positive offset encodingAmaury de la Vieuville2013-06-181-1/+1
| | | | | | | | | | | | When using a positive offset, literal loads where encoded as if it was negative, because: - The sign bit was not assigned to an operand - The addrmode_imm12 operand was not encoding the sign bit correctly This patch also makes the assembler look at the .w/.n specifier for loads. llvm-svn: 184182
* Use pointers to the MCAsmInfo and MCRegInfo.Bill Wendling2013-06-181-31/+31
| | | | | | | | | Someone may want to do something crazy, like replace these objects if they change or something. No functionality change intended. llvm-svn: 184175
* Replace Count{Leading,Trailing}Zeros_{32,64} with count{Leading,Trailing}Zeros.Michael J. Spencer2013-05-241-2/+2
| | | | llvm-svn: 182680
* ARM: permit full range of valid ADR immediates.Tim Northover2013-02-271-2/+15
| | | | | | | | | This fixes an issue where trying to assemlbe valid ADR instructions would cause LLVM to hit a failed assertion. Patch by Keith Walker. llvm-svn: 176189
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-3/+3
| | | | | | | | | | | | | | | | | 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
* Fix the handling of edge cases in ARM shifted operands.Tim Northover2012-09-221-0/+4
| | | | | | | | | This patch fixes load/store instructions to handle less common cases like "asr #32", "rrx" properly throughout the MC layer. Patch by Chris Lidbury. llvm-svn: 164455
* Use LLVM_DELETED_FUNCTION in place of 'DO NOT IMPLEMENT' comments.Craig Topper2012-09-151-2/+2
| | | | llvm-svn: 163974
* Fix undefined behavior (negation of INT_MIN) in ARM backend.Richard Smith2012-08-241-1/+1
| | | | llvm-svn: 162520
* Remove getARMRegisterNumbering and replace with calls intoEric Christopher2012-08-091-32/+34
| | | | | | | | | | | the register info for getEncodingValue. This builds on the small patch of yesterday to set HWEncoding in the register file. One (deprecated) use was turned into a hard number to avoid needing register info in the old JIT. llvm-svn: 161628
* Fix #13241, a bug around shift immediate operand for ARM instruction ADR.Jiangning Liu2012-08-021-7/+17
| | | | llvm-svn: 161159
* Allow MCCodeEmitter access to the target MCRegisterInfo.Jim Grosbach2012-05-151-0/+1
| | | | | | | | Add the MCRegisterInfo to the factories and constructors. Patch by Tom Stellard <Tom.Stellard@amd.com>. llvm-svn: 156828
* ARM: allow vanilla expressions for movw/movt.Jim Grosbach2012-05-011-4/+16
| | | | | | | | | | Expressions for movw/movt don't always have an :upper16: or :lower16: on them and that's ok. When they don't, it's just a plain [0-65536] immediate result, effectively the same as a :lower16: variant kind. rdar://10550147 llvm-svn: 155941
* Unify internal representation of ARM instructions with a register ↵Richard Barton2012-04-251-2/+1
| | | | | | right-shifted by #32. These are stored as shifts by #0 in the MCInst and correctly marshalled when transforming from or to assembly representation. llvm-svn: 155565
* Ensure conditional BL instructions for ARM are given the fixup ↵James Molloy2012-03-301-2/+6
| | | | | | | | fixup_arm_condbranch. Patch by Tim Northover! llvm-svn: 153737
* Remove unnecessary llvm:: qualificationsCraig Topper2012-03-271-2/+2
| | | | llvm-svn: 153500
* ARM BL/BLX instruction fixups should use relocations.Jim Grosbach2012-02-271-8/+15
| | | | | | | | | | | | | We on the linker to resolve calls to the appropriate BL/BLX instruction to make interworking function correctly. It uses the symbol in the relocation to do that, so we need to be careful about being too clever. To enable this for ARM mode, split the BL/BLX fixup kind off from the unconditional-branch fixups. rdar://10927209 llvm-svn: 151571
* Convert assert(0) to llvm_unreachableCraig Topper2012-02-071-3/+3
| | | | llvm-svn: 149961
* Keep source information, if available, around for ARM Fixups.Jim Grosbach2012-01-261-6/+6
| | | | | | | | | | | | | | | | | Adjust an example MachObjectWriter diagnostic to use the information to issue a better message. Before: LLVM ERROR: unknown ARM fixup kind! After: x.s:6:5: error: unsupported relocation on symbol beq bar ^ rdar://9800182 llvm-svn: 149093
* Widen the instruction encoder that TblGen emits to a 64 bits, which should ↵Owen Anderson2012-01-241-1/+1
| | | | | | accomodate every target I can think of offhand. llvm-svn: 148833
* More dead code removal (using -Wunreachable-code)David Blaikie2012-01-201-3/+1
| | | | llvm-svn: 148578
* Thumb2 alternate syntax for LDR(literal) and friends.Jim Grosbach2012-01-181-0/+1
| | | | | | | | Explicit pc-relative syntax. For example, "ldrb r2, [pc, #-22]". rdar://10250964 llvm-svn: 148432
* Remove unnecessary default cases in switches that cover all enum values.David Blaikie2012-01-101-1/+0
| | | | llvm-svn: 147855
* ARM assembly parsing and encoding support for LDRD(label).Jim Grosbach2011-12-191-1/+14
| | | | | | rdar://9932658 llvm-svn: 146921
* ARM NEON relax parse time diagnostics for alignment specifiers.Jim Grosbach2011-12-191-4/+4
| | | | | | | There's more variation that we need to handle. Error checking will need to be on operand predicates. llvm-svn: 146884
* ARM encoder method needs the physical register number, not the enum.Jim Grosbach2011-12-021-1/+1
| | | | llvm-svn: 145711
OpenPOWER on IntegriCloud