summaryrefslogtreecommitdiffstats
path: root/llvm/lib/MC/MCExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* clang-format bits of code to make another patch readable.Rafael Espindola2015-03-251-18/+11
| | | | llvm-svn: 233203
* Fix fixup evaluation when deciding what to relocate with.Rafael Espindola2015-03-251-38/+30
| | | | | | | | | | | | | | The previous logic was to first try without relocations at all and failing that stop on the first defined symbol. That was inefficient and incorrect in the case part of the expression could be simplified and another part could not (see included test). We now stop the evaluation when we get to a variable whose value can change (i.e. is weak). llvm-svn: 233187
* Produce an error instead of asserting on invalid .sleb128/.uleb128.Rafael Espindola2015-03-251-7/+4
| | | | llvm-svn: 233155
* Expand variables when evaluating absolute expressions.Rafael Espindola2015-03-041-1/+1
| | | | | | | This allows for variables to be used in .size. This matches gnu AS functionality. llvm-svn: 231295
* [MC][Target] Implement support for R_X86_64_SIZE{32,64}.Davide Italiano2015-03-041-0/+2
| | | | | | | Differential Revision: D7990 Reviewed by: rafael, majnemer llvm-svn: 231216
* ARM: add support for segment base relocations (SBREL)Saleem Abdulrasool2015-01-111-0/+2
| | | | | | | | This adds support for parsing and emitting the SBREL relocation variant for the ARM target. Handling this relocation variant is necessary for supporting the full ARM ELF specification. Addresses PR22128. llvm-svn: 225595
* Instead of explicitely comparing both lowercase and uppercase variants.Roman Divacky2014-12-181-81/+1
| | | | | | | | | | .lower() the Name and compare only the lowecase. Removing 81 compares/lines of code. This changes the accepted string to be mixed lower/upper case but it should be ok. Discussed with Jim Grosbach. llvm-svn: 224547
* Add a corresponding '@LOCAL' parse to match r224415.Justin Hibbits2014-12-181-0/+1
| | | | | | Pointed out by Jim Grosbach. llvm-svn: 224494
* Add parsing of 'foo@local".Justin Hibbits2014-12-171-0/+1
| | | | | | | | | | | | | | | | | | Summary: Currently, it supports generating, but not parsing, this expression. Test added as well. Test Plan: New test added, no regressions due to this. Reviewers: hfinkel Reviewed By: hfinkel Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6672 llvm-svn: 224415
* Add support for small-model PIC for PowerPC.Justin Hibbits2014-11-121-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: Large-model was added first. With the addition of support for multiple PIC models in LLVM, now add small-model PIC for 32-bit PowerPC, SysV4 ABI. This generates more optimal code, for shared libraries with less than about 16380 data objects. Test Plan: Test cases added or updated Reviewers: joerg, hfinkel Reviewed By: hfinkel Subscribers: jholewinski, mcrosier, emaste, llvm-commits Differential Revision: http://reviews.llvm.org/D5399 llvm-svn: 221791
* MC: Shrink MCSymbolRefExpr by only storing the bits we need.Benjamin Kramer2014-10-111-8/+19
| | | | | | 32 -> 16 bytes on x86_64. NFC. llvm-svn: 219574
* MC: Use @IMGREL instead of @IMGREL32, which we can't parseReid Kleckner2014-09-251-1/+1
| | | | | | | | | | | | Nico Rieck added support for this 32-bit COFF relocation some time ago for Win64 stuff. It appears that as an oversight, the assembly output used "foo"@IMGREL32 instead of "foo"@IMGREL, which is what we can parse. Sadly, there were actually tests that took in IMGREL and put out IMGREL32, and we didn't notice the inconsistency. Oh well. Now LLVM can assemble it's own output with slightly more fidelity. llvm-svn: 218437
* Add a helper to MCExpr for when an expression is know to be absolute.Rafael Espindola2014-08-151-6/+20
| | | | llvm-svn: 215713
* Fix tabs.Joerg Sonnenberger2014-08-101-4/+4
| | | | llvm-svn: 215311
* If available, pass down the Fixup object to EvaluateAsRelocatable.Joerg Sonnenberger2014-08-101-16/+23
| | | | | | | At least on PowerPC, the interpretation of certain modifiers depends on the context they appear in. llvm-svn: 215310
* [mips][mips64r6] Add Relocations R_MIPS_PCHI16, R_MIPS_PCLO16 Zoran Jovanovic2014-05-271-0/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D3860 llvm-svn: 209659
* Fix pr19645.Rafael Espindola2014-05-031-2/+1
| | | | | | | | | | | | | | | | The fix itself is fairly simple: move getAccessVariant to MCValue so that we replace the old weak expression evaluation with the far more general EvaluateAsRelocatable. This then requires that EvaluateAsRelocatable stop when it finds a non trivial reference kind. And that in turn requires the ELF writer to look harder for weak references. Last but not least, this found a case where we were being bug by bug compatible with gas and accepting an invalid input. I reported pr19647 to track it. llvm-svn: 207920
* Parse and create GOT_PREL relocations.Joerg Sonnenberger2014-04-291-0/+2
| | | | llvm-svn: 207526
* Add an option for evaluating past symbols.Rafael Espindola2014-04-281-17/+26
| | | | | | | | | | | | | When evaluating an assembly expression for a relocation, we want to stop at MCSymbols that are in the symbol table, even if they are variables. This is needed since the semantics may require that the relocation use them. That is not the case when computing the value of a symbol in the symbol table. There are no relocations in this case and we have to keep going until we hit a section or find out that the expression doesn't have an assembly time value. llvm-svn: 207445
* Spread some const around for non-mutating uses of MCSymbolData.David Blaikie2014-04-241-2/+2
| | | | | | | | I discovered this const-hole while attempting to coalesnce the Symbol and SymbolMap data structures. There's some pending issues with that, but I figured this change was easy to flush early. llvm-svn: 207124
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | definition below all the header #include lines. This updates most of the miscellaneous other lib/... directories. A few left though. llvm-svn: 206845
* [C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper2014-04-131-9/+9
| | | | | | check instead of comparing to nullptr. llvm-svn: 206129
* ARM64: initial backend importTim Northover2014-03-291-0/+18
| | | | | | | | | | | | This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
* Look through variables when computing relocations.Rafael Espindola2014-03-201-9/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given bar = foo + 4 .long bar MC would eat the 4. GNU as includes it in the relocation. The rule seems to be that a variable that defines a symbol is used in the relocation and one that does not define a symbol is evaluated and the result included in the relocation. Fixing this unfortunately required some other changes: * Since the variable is now evaluated, it would prevent the ELF writer from noticing the weakref marker the elf streamer uses. This patch then replaces that with a VariantKind in MCSymbolRefExpr. * Using VariantKind then requires us to look past other VariantKind to see .weakref bar,foo call bar@PLT doing this also fixes zed = foo +2 call zed@PLT so that is a good thing. * Looking past VariantKind means that the relocation selection has to use the fixup instead of the target. This is a reboot of the previous fixes for MC. I will watch the sanitizer buildbot and wait for a build before adding back the previous fixes. llvm-svn: 204294
* Try harder to evaluate expressions when printing assembly.Rafael Espindola2014-03-121-3/+3
| | | | | | | | | When printing assembly we don't have a Layout object, but we can still try to fold some constants. Testcase by Ulrich Weigand. llvm-svn: 203677
* ARM: suuport .tlsdescseq directiveSaleem Abdulrasool2014-01-301-0/+1
| | | | | | | | | | | This enhances the ARMAsmParser to handle .tlsdescseq directives. This is a slightly special relocation. We must be able to generate them, but not consume them in assembly. The relocation is meant to assist the linker in generating a TLS descriptor sequence. The ELF target streamer is enhanced to append additional fixups into the current segment and that is used to emit the new R_ARM_TLS_DESCSEQ relocations. llvm-svn: 200448
* ARM: support TLS descriptor relocationsSaleem Abdulrasool2014-01-301-0/+3
| | | | | | | | Add support for tlsdesc relocations which are part of the ABI, marked as experimental. These relocations permit the linker to perform TLS reference optimizations. llvm-svn: 200447
* ARM: support tlscall relocationsSaleem Abdulrasool2014-01-301-0/+3
| | | | | | | | | | | | | | This adds support for TLS CALL relocations. TLS CALL relocations are used to indicate to the linker to generate appropriate entries to resolve TLS references via an appropriate function invocation (e.g. __tls_get_addr(PLT)). In order to accomodate the linker relaxation of the TLS access model for the references (GD/LD -> IE, IE -> LE), the relocation addend must be incomplete. This requires that the partial inplace value is also incomplete (i.e. 0). We simply avoid the offset value calculation at the time of the fixup adjustment in the ARM assembler backend. llvm-svn: 200446
* ARM: add tlsldo relocationKai Nacke2014-01-201-0/+3
| | | | | | | | | Add support for the symbol(tlsldo) relocation. This is required in order to solve PR18554. Reviewed by R. Golin, A. Korobeynikov. llvm-svn: 199644
* Add support for parsing ARM symbol variants on ELF targetsDavid Peixotto2013-12-041-24/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PowerPC] Revert r185476 and fix up TLS variant kindsUlrich Weigand2013-07-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the commit message to r185476 I wrote: >The PowerPC-specific modifiers VK_PPC_TLSGD and VK_PPC_TLSLD >correspond exactly to the generic modifiers VK_TLSGD and VK_TLSLD. >This causes some confusion with the asm parser, since VK_PPC_TLSGD >is output as @tlsgd, which is then read back in as VK_TLSGD. > >To avoid this confusion, this patch removes the PowerPC-specific >modifiers and uses the generic modifiers throughout. (The only >drawback is that the generic modifiers are printed in upper case >while the usual convention on PowerPC is to use lower-case modifiers. >But this is just a cosmetic issue.) This was unfortunately incorrect, there is is fact another, serious drawback to using the default VK_TLSLD/VK_TLSGD variant kinds: using these causes ELFObjectWriter::RelocNeedsGOT to return true, which in turn causes the ELFObjectWriter to emit an undefined reference to _GLOBAL_OFFSET_TABLE_. This is a problem on powerpc64, because it uses the TOC instead of the GOT, and the linker does not provide _GLOBAL_OFFSET_TABLE_, so the symbol remains undefined. This means shared libraries using TLS built with the integrated assembler are currently broken. While the whole RelocNeedsGOT / _GLOBAL_OFFSET_TABLE_ situation probably ought to be properly fixed at some point, for now I'm simply reverting the r185476 commit. Now this in turn exposes the breakage of handling @tlsgd/@tlsld in the asm parser that this check-in was originally intended to fix. To avoid this regression, I'm also adding a different fix for this problem: while common code now parses @tlsgd as VK_TLSGD, a special hack in the asm parser translates this code to the platform-specific VK_PPC_TLSGD that the back-end now expects. While this is not really pretty, it's self-contained and shouldn't hurt anything else for now. One the underlying problem is fixed, this hack can be reverted again. llvm-svn: 185945
* [PowerPC] Remove VK_PPC_TLSGD and VK_PPC_TLSLDUlrich Weigand2013-07-021-2/+0
| | | | | | | | | | | | | | | The PowerPC-specific modifiers VK_PPC_TLSGD and VK_PPC_TLSLD correspond exactly to the generic modifiers VK_TLSGD and VK_TLSLD. This causes some confusion with the asm parser, since VK_PPC_TLSGD is output as @tlsgd, which is then read back in as VK_TLSGD. To avoid this confusion, this patch removes the PowerPC-specific modifiers and uses the generic modifiers throughout. (The only drawback is that the generic modifiers are printed in upper case while the usual convention on PowerPC is to use lower-case modifiers. But this is just a cosmetic issue.) llvm-svn: 185476
* [PowerPC] Add support for TLS data relocationsUlrich Weigand2013-07-011-0/+3
| | | | | | | | | | This adds support for TLS data relocations and modifiers: .quad target@dtpmod .quad target@tprel .quad target@dtprel Currently exploited by the asm parser only. llvm-svn: 185394
* [PowerPC] Support @got modifierUlrich Weigand2013-06-251-0/+9
| | | | | | | Add VK_... values and relocation types necessary to support the @got family of modifiers. Used by the asm parser only. llvm-svn: 184860
* [PowerPC] Support various tls-related modifiersUlrich Weigand2013-06-211-0/+66
| | | | | | | | | | The current code base only supports the minimum set of tls-related relocations and @modifiers that are necessary to support compiler- generated code. This patch extends this to the full set defined in the ABI (and supported by the GNU assembler) for the benefit of the assembler parser. llvm-svn: 184551
* [PowerPC] Support @higher et.al. modifiersUlrich Weigand2013-06-211-0/+12
| | | | | | | This adds support for the @higher, @highera, @highest, and @highesta modifers, including some missing relocation types. llvm-svn: 184550
* [PowerPC] Support @toc@h modifierUlrich Weigand2013-06-211-0/+3
| | | | | | | This adds the relocation type and other necessary infrastructure to use the @toc@h modifier in the assembler. llvm-svn: 184549
* [PowerPC] Support @h modifierUlrich Weigand2013-06-211-0/+3
| | | | | | | | | | | | This adds necessary infrastructure to support the @h modifier. Note that all required relocation types were already present (and unused). This patch provides support for using @h in the assembler; it would also be possible to now use this feature in code generated by the compiler, but this is not done yet. llvm-svn: 184548
* [PowerPC] Rename some more VK_PPC_ enumsUlrich Weigand2013-06-211-45/+45
| | | | | | | | | | | | | This renames more VK_PPC_ enums, to make them more closely reflect the @modifier string they represent. This also prepares for adding a bunch of new VK_PPC_ enums in upcoming patches. For consistency, some MO_ flags related to VK_PPC_ enums are likewise renamed. No change in behaviour. llvm-svn: 184547
* [PowerPC] Clean up VK_PPC_TOC... namesUlrich Weigand2013-06-201-8/+8
| | | | | | | | | | | | This is another minor cleanup; to bring enum names in line with the corresponding @modifier names, this renames: VK_PPC_TOC -> VK_PPC_TOCBASE VK_PPC_TOC_ENTRY -> VK_PPC_TOC16 No code change intended. llvm-svn: 184491
* [PowerPC] Clean up generation of ha16() / lo16() markersUlrich Weigand2013-05-231-18/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When targeting the Darwin assembler, we need to generate markers ha16() and lo16() to designate the high and low parts of a (symbolic) immediate. This is necessary not just for plain symbols, but also for certain symbolic expression, typically along the lines of ha16(A - B). The latter doesn't work when simply using VariantKind flags on the symbol reference. This is why the current back-end uses hacks (explicitly called out as such via multiple FIXMEs) in the symbolLo/symbolHi print methods. This patch uses target-defined MCExpr codes to represent the Darwin ha16/lo16 constructs, following along the lines of the equivalent solution used by the ARM back end to handle their :upper16: / :lower16: markers. This allows us to get rid of special handling both in the symbolLo/symbolHi print method and in the common code MCExpr::print routine. Instead, the ha16 / lo16 markers are printed simply in a custom print routine for the target MCExpr types. (As a result, the symbolLo/symbolHi print methods can now replaced by a single printS16ImmOperand routine that also handles symbolic operands.) The patch also provides a EvaluateAsRelocatableImpl routine to handle ha16/lo16 constructs. This is not actually used at the moment by any in-tree code, but is provided as it makes merging into David Fang's out-of-tree Mach-O object writer simpler. Since there is no longer any need to treat VK_PPC_GAS_HA16 and VK_PPC_DARWIN_HA16 differently, they are merged into a single VK_PPC_ADDR16_HA (and likewise for the _LO16 types). llvm-svn: 182616
* [PowerPC] Parse platform-specifc variant kinds in AsmParserUlrich Weigand2013-05-031-0/+34
| | | | | | | | | This patch adds support for PowerPC platform-specific variant kinds in MCSymbolRefExpr::getVariantKindForName, and also adds a test case to verify they are translated to the appropriate fixup type. llvm-svn: 181053
* Fix section relocation for SECTIONREL32 with immediate offset.Rafael Espindola2013-04-251-0/+2
| | | | | | Patch by Kai Nacke. This matches the gnu as output. llvm-svn: 180568
* MC: Support COFF image-relative MCSymbolRefsNico Rieck2013-04-101-0/+3
| | | | | | | | | | | | | | | | Add support for the COFF relocation types IMAGE_REL_I386_DIR32NB and IMAGE_REL_AMD64_ADDR32NB for 32- and 64-bit respectively. These are similar to normal 4-byte relocations except that they do not include the base address of the image. Image-relative relocations are used for debug information (32-bit) and SEH unwind tables (64-bit). A new MCSymbolRef variant called 'VK_COFF_IMGREL32' is introduced to specify such relocations. For AT&T assembly, this variant can be accessed using the symbol suffix '@imgrel'. llvm-svn: 179240
* Change '@SECREL' suffix to GAS-compatible '@SECREL32'.Benjamin Kramer2013-03-301-1/+1
| | | | | | | | | | '@SECREL' is what is used by the Microsoft assembler, but GNU as expects '@SECREL32'. With the patch, the MC-generated code works fine in combination with a recent GNU as (2.23.51.20120920 here). Patch by David Nadlinger! Differential Revision: http://llvm-reviews.chandlerc.com/D429 llvm-svn: 178427
* This patch improves the 64-bit PowerPC InitialExec TLS support by providingBill Schmidt2012-12-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | for a wider range of GOT entries that can hold thread-relative offsets. This matches the behavior of GCC, which was not documented in the PPC64 TLS ABI. The ABI will be updated with the new code sequence. Former sequence: ld 9,x@got@tprel(2) add 9,9,x@tls New sequence: addis 9,2,x@got@tprel@ha ld 9,x@got@tprel@l(9) add 9,9,x@tls Note that a linker optimization exists to transform the new sequence into the shorter sequence when appropriate, by replacing the addis with a nop and modifying the base register and relocation type of the ld. llvm-svn: 170209
* This patch implements local-dynamic TLS model support for the 64-bitBill Schmidt2012-12-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | PowerPC target. This is the last of the four models, so we now have full TLS support. This is mostly a straightforward extension of the general dynamic model. I had to use an additional Chain operand to tie ADDIS_DTPREL_HA to the register copy following ADDI_TLSLD_L; otherwise everything above the ADDIS_DTPREL_HA appeared dead and was removed. As before, there are new test cases to test the assembly generation, and the relocations output during integrated assembly. The expected code gen sequence can be read in test/CodeGen/PowerPC/tls-ld.ll. There are a couple of things I think can be done more efficiently in the overall TLS code, so there will likely be a clean-up patch forthcoming; but for now I want to be sure the functionality is in place. Bill llvm-svn: 170003
* Add ARM NONE and PREL31 relocation types.Logan Chien2012-12-121-2/+6
| | | | | | | | Add R_ARM_NONE and R_ARM_PREL31 relocation types to MCExpr. Both of them will be used while generating .ARM.extab and .ARM.exidx sections. llvm-svn: 169965
* This patch implements the general dynamic TLS model for 64-bit PowerPC.Bill Schmidt2012-12-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given a thread-local symbol x with global-dynamic access, the generated code to obtain x's address is: Instruction Relocation Symbol addis ra,r2,x@got@tlsgd@ha R_PPC64_GOT_TLSGD16_HA x addi r3,ra,x@got@tlsgd@l R_PPC64_GOT_TLSGD16_L x bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x R_PPC64_REL24 __tls_get_addr nop <use address in r3> The implementation borrows from the medium code model work for introducing special forms of ADDIS and ADDI into the DAG representation. This is made slightly more complicated by having to introduce a call to the external function __tls_get_addr. Using the full call machinery is overkill and, more importantly, makes it difficult to add a special relocation. So I've introduced another opcode GET_TLS_ADDR to represent the function call, and surrounded it with register copies to set up the parameter and return value. Most of the code is pretty straightforward. I ran into one peculiarity when I introduced a new PPC opcode BL8_NOP_ELF_TLSGD, which is just like BL8_NOP_ELF except that it takes another parameter to represent the symbol ("x" above) that requires a relocation on the call. Something in the TblGen machinery causes BL8_NOP_ELF and BL8_NOP_ELF_TLSGD to be treated identically during the emit phase, so this second operand was never visited to generate relocations. This is the reason for the slightly messy workaround in PPCMCCodeEmitter.cpp:getDirectBrEncoding(). Two new tests are included to demonstrate correct external assembly and correct generation of relocations using the integrated assembler. Comments welcome! Thanks, Bill llvm-svn: 169910
* This patch introduces initial-exec model support for thread-local storageBill Schmidt2012-12-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | on 64-bit PowerPC ELF. The patch includes code to handle external assembly and MC output with the integrated assembler. It intentionally does not support the "old" JIT. For the initial-exec TLS model, the ABI requires the following to calculate the address of external thread-local variable x: Code sequence Relocation Symbol ld 9,x@got@tprel(2) R_PPC64_GOT_TPREL16_DS x add 9,9,x@tls R_PPC64_TLS x The register 9 is arbitrary here. The linker will replace x@got@tprel with the offset relative to the thread pointer to the generated GOT entry for symbol x. It will replace x@tls with the thread-pointer register (13). The two test cases verify correct assembly output and relocation output as just described. PowerPC-specific selection node variants are added for the two instructions above: LD_GOT_TPREL and ADD_TLS. These are inserted when an initial-exec global variable is encountered by PPCTargetLowering::LowerGlobalTLSAddress(), and later lowered to machine instructions LDgotTPREL and ADD8TLS. LDgotTPREL is a pseudo that uses the same LDrs support added for medium code model's LDtocL, with a different relocation type. The rest of the processing is straightforward. llvm-svn: 169281
OpenPOWER on IntegriCloud