summaryrefslogtreecommitdiffstats
path: root/llvm/test/Linker
Commit message (Collapse)AuthorAgeFilesLines
* Remove irrelevant references to legacy git repositories fromJames Y Knight2019-01-158-10/+10
| | | | | | | | | compiler identification lines in test-cases. (Doing so only because it's then easier to search for references which are actually important and need fixing.) llvm-svn: 351200
* Implement -frecord-command-line (-frecord-gcc-switches)Scott Linder2018-12-143-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | Implement options in clang to enable recording the driver command-line in an ELF section. Implement a new special named metadata, llvm.commandline, to support frontends embedding their command-line options in IR/ASM/ELF. This differs from the GCC implementation in some key ways: * In GCC there is only one command-line possible per compilation-unit, in LLVM it mirrors llvm.ident and multiple are allowed. * In GCC individual options are separated by NULL bytes, in LLVM entire command-lines are separated by NULL bytes. The advantage of the GCC approach is to clearly delineate options in the face of embedded spaces. The advantage of the LLVM approach is to support merging multiple command-lines unambiguously, while handling embedded spaces with escaping. Differential Revision: https://reviews.llvm.org/D54487 Clang Differential Revision: https://reviews.llvm.org/D54489 llvm-svn: 349155
* [DebugInfo] IR/Bitcode changes for DISubprogram flags.Paul Robinson2018-11-281-1/+1
| | | | | | | | | Packing the flags into one bitcode word will save effort in adding new flags in the future. Differential Revision: https://reviews.llvm.org/D54755 llvm-svn: 347806
* llvm-link: Improve diagnostic for module-level metadata mismatchDavid Blaikie2018-10-093-0/+8
| | | | | | | | | | | | This might produce hard to read/illegible diagnostics for especially weird/non-trivial module metadata but integers are about all we are using these days, so seems more useful than not. Patch based on work by Kristina Brooks - thanks! Differential Revision: https://reviews.llvm.org/D52952 llvm-svn: 344011
* Fix asserts when linking wrong address space declarationsMatt Arsenault2018-09-242-0/+19
| | | | llvm-svn: 342858
* [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.Shiva Chen2018-05-0924-48/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
* [llvm-link] Use WithColor for printing errorsJonas Devlieghere2018-04-185-11/+11
| | | | | | | | Use convenience helpers in WithColor to print errors and warnings. Differential revision: https://reviews.llvm.org/D45667 llvm-svn: 330261
* [DebugInfo] Add remaining files to r325970Scott Linder2018-02-233-0/+48
| | | | | | Add files which I missed in the original check-in llvm-svn: 325973
* [DebugInfo] Support DWARF v5 source code embedding extensionScott Linder2018-02-231-4/+8
| | | | | | | | | | | | | | | | | | | In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. In this extension a content type is added, DW_LNCT_LLVM_source, which contains the embedded source code of the file. Add new optional attribute for !DIFile IR metadata called source which contains source text. Use this to output the source to the DWARF line table of code objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM to support optional source. Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output format of llvm-dwarfdump to make room for the new attribute on file_names entries, and support embedded sources for the -source option in llvm-objdump. Differential Revision: https://reviews.llvm.org/D42765 llvm-svn: 325970
* Revert "[IRMover] Implement name based structure type mapping"Rafael Espindola2018-02-212-16/+0
| | | | | | | | This reverts commit r325686. There was a misunderstanding and this has not been approved yet. llvm-svn: 325715
* [IRMover] Implement name based structure type mappingEugene Leviant2018-02-212-0/+16
| | | | | | Differential revision: https://reviews.llvm.org/D43199 llvm-svn: 325686
* [DWARF] Regularize dumping strings from line tables.Paul Robinson2018-02-051-4/+4
| | | | | | | | | | | | | | | | | The major visible difference here is that in line-table dumps, directory and file names are wrapped in double-quotes; previously, directory names got single quotes and file names were not quoted at all. The improvement in this patch is that when a DWARF v5 line table header has indirect strings, in a verbose dump these will all have their section[offset] printed as well as the name itself. This matches the format used for dumping strings in the .debug_info section. Differential Revision: https://reviews.llvm.org/D42802 llvm-svn: 324270
* [IRMover] Add comment and fix test caseEugene Leviant2018-01-251-1/+5
| | | | llvm-svn: 323407
* Remove alignment argument from memcpy/memmove/memset in favour of alignment ↵Daniel Neilson2018-01-193-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | attributes (Step 1) Summary: This is a resurrection of work first proposed and discussed in Aug 2015: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html and initially landed (but then backed out) in Nov 2015: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument which is required to be a constant integer. It represents the alignment of the dest (and source), and so must be the minimum of the actual alignment of the two. This change is the first in a series that allows source and dest to each have their own alignments by using the alignment attribute on their arguments. In this change we: 1) Remove the alignment argument. 2) Add alignment attributes to the source & dest arguments. We, temporarily, require that the alignments for source & dest be equal. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false) will now read call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false) Downstream users may have to update their lit tests that check for @llvm.memcpy/memmove/memset call/declaration patterns. The following extended sed script may help with updating the majority of your tests, but it does not catch all possible patterns so some manual checking and updating will be required. s~declare void @llvm\.mem(set|cpy|move)\.p([^(]*)\((.*), i32, i1\)~declare void @llvm.mem\1.p\2(\3, i1)~g s~call void @llvm\.memset\.p([^(]*)i8\(i8([^*]*)\* (.*), i8 (.*), i8 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i8(i8\2* \3, i8 \4, i8 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i16\(i8([^*]*)\* (.*), i8 (.*), i16 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i16(i8\2* \3, i8 \4, i16 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i32\(i8([^*]*)\* (.*), i8 (.*), i32 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i32(i8\2* \3, i8 \4, i32 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i64\(i8([^*]*)\* (.*), i8 (.*), i64 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i64(i8\2* \3, i8 \4, i64 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i128\(i8([^*]*)\* (.*), i8 (.*), i128 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.memset.p\1i128(i8\2* \3, i8 \4, i128 \5, i1 \6)~g s~call void @llvm\.memset\.p([^(]*)i8\(i8([^*]*)\* (.*), i8 (.*), i8 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i8(i8\2* align \6 \3, i8 \4, i8 \5, i1 \7)~g s~call void @llvm\.memset\.p([^(]*)i16\(i8([^*]*)\* (.*), i8 (.*), i16 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i16(i8\2* align \6 \3, i8 \4, i16 \5, i1 \7)~g s~call void @llvm\.memset\.p([^(]*)i32\(i8([^*]*)\* (.*), i8 (.*), i32 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i32(i8\2* align \6 \3, i8 \4, i32 \5, i1 \7)~g s~call void @llvm\.memset\.p([^(]*)i64\(i8([^*]*)\* (.*), i8 (.*), i64 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i64(i8\2* align \6 \3, i8 \4, i64 \5, i1 \7)~g s~call void @llvm\.memset\.p([^(]*)i128\(i8([^*]*)\* (.*), i8 (.*), i128 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.memset.p\1i128(i8\2* align \6 \3, i8 \4, i128 \5, i1 \7)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i8\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i8 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i8(i8\3* \4, i8\5* \6, i8 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i16\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i16 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i16(i8\3* \4, i8\5* \6, i16 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i32\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i32 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i32(i8\3* \4, i8\5* \6, i32 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i64\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i64 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i64(i8\3* \4, i8\5* \6, i64 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i128\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i128 (.*), i32 [01], i1 ([^)]*)\)~call void @llvm.mem\1.p\2i128(i8\3* \4, i8\5* \6, i128 \7, i1 \8)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i8\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i8 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i8(i8\3* align \8 \4, i8\5* align \8 \6, i8 \7, i1 \9)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i16\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i16 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i16(i8\3* align \8 \4, i8\5* align \8 \6, i16 \7, i1 \9)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i32\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i32 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i32(i8\3* align \8 \4, i8\5* align \8 \6, i32 \7, i1 \9)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i64\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i64 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i64(i8\3* align \8 \4, i8\5* align \8 \6, i64 \7, i1 \9)~g s~call void @llvm\.mem(cpy|move)\.p([^(]*)i128\(i8([^*]*)\* (.*), i8([^*]*)\* (.*), i128 (.*), i32 ([0-9]*), i1 ([^)]*)\)~call void @llvm.mem\1.p\2i128(i8\3* align \8 \4, i8\5* align \8 \6, i128 \7, i1 \9)~g The remaining changes in the series will: Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. Step 3) Update Clang to use the new IRBuilder API. Step 4) Update Polly to use the new IRBuilder API. Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use getDestAlignment() and getSourceAlignment() instead. Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reviewers: pete, hfinkel, lhames, reames, bollu Reviewed By: reames Subscribers: niosHD, reames, jholewinski, qcolombet, jfb, sanjoy, arsenm, dschuff, dylanmckay, mehdi_amini, sdardis, nemanjai, david2050, nhaehnle, javed.absar, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, llvm-commits Differential Revision: https://reviews.llvm.org/D41675 llvm-svn: 322965
* Make GlobalValues with non-default visibilility dso_local.Rafael Espindola2018-01-181-9/+9
| | | | | | | | | | | | This is similar to r322317, but for visibility. It is not as neat because we have to special case extern_weak. The idea is the same as the previous change, make the transition to explicit dso_local easier for the frontends. With this they only have to add dso_local to symbols where we need some external information to decide if it is dso_local (like it being part of an ELF executable). llvm-svn: 322806
* Make internal/private GVs implicitly dso_local.Rafael Espindola2018-01-111-9/+9
| | | | | | | | | | | | | | | | While updating clang tests for having clang set dso_local I noticed that: - There are *a lot* of tests to update. - Many of the updates are redundant. They are redundant because a GV is "obviously dso_local". This patch starts formalizing that a bit by requiring that internal and private GVs be dso_local too. Since they all are, we don't have to print dso_local to the textual representation, making it a bit more compact and easier to read. llvm-svn: 322317
* Verifier: Ignore CUs pulled in by ODR-uniqued types.Adrian Prantl2017-10-182-0/+200
| | | | | | | | | | | | | | | When more than one Module is imported into the same context, such as during an LTO build before linking the modules, ODR type uniquing may cause types to point to a different CU. This check does not make sense in this case. This fixes the error reported in PR34944. https://bugs.llvm.org/show_bug.cgi?id=34944 rdar://problem/34940685 This reapplies a cleaner implementation of r316049. llvm-svn: 316052
* Revert "Verifier: Ignore CUs pulled in by ODR-uniqued types."Adrian Prantl2017-10-182-200/+0
| | | | | | This reverts commit r316049. llvm-svn: 316050
* Verifier: Ignore CUs pulled in by ODR-uniqued types.Adrian Prantl2017-10-182-0/+200
| | | | | | | | | | | | | When more than one Module is imported into the same context, such as during an LTO build before linking the modules, ODR type uniquing may cause types to point to a different CU. This check does not make sense in this case. This fixes the error reported in PR34944. https://bugs.llvm.org/show_bug.cgi?id=34944 rdar://problem/34940685 llvm-svn: 316049
* Re-land "[llvm-dwarfdump] Print type names in DW_AT_type DIEs"Jonas Devlieghere2017-10-103-5/+5
| | | | | | | | | | | | This patch adds printing for DW_AT_type DIEs like it is already the case for DW_AT_specification DIEs. This is a rather naive approach and only a start. We should have pretty printers for different languages. Recommit after being reverted in r315299. Differential revision: https://reviews.llvm.org/D36993 llvm-svn: 315316
* Revert "[llvm-dwarfdump] Print type names in DW_AT_type DIEs"Jonas Devlieghere2017-10-103-5/+5
| | | | | | This reverts commit r315297. llvm-svn: 315299
* [llvm-dwarfdump] Print type names in DW_AT_type DIEsJonas Devlieghere2017-10-103-5/+5
| | | | | | | | | | This patch adds printing for DW_AT_type DIEs like it is already the case for DW_AT_specification DIEs. This is a rather naive approach and only a start. We should have pretty printers for different languages. Differential revision: https://reviews.llvm.org/D36993 llvm-svn: 315297
* llvm-dwarfdump: Make -brief the default and add a -verbose option instead.Adrian Prantl2017-09-115-6/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D37717 llvm-svn: 312972
* llvm-dwarfdump: Replace -debug-dump=sect option with individual options.Adrian Prantl2017-09-116-8/+8
| | | | | | | | | | | | | | | | | | | | | | As discussed on llvm-dev in http://lists.llvm.org/pipermail/llvm-dev/2017-September/117301.html this changes the command line interface of llvm-dwarfdump to match the one used by the dwarfdump utility shipping on macOS. In addition to being shorter to type this format also has the advantage of allowing more than one section to be specified at the same time. In a nutshell, with this change $ llvm-dwarfdump --debug-dump=info $ llvm-dwarfdump --debug-dump=apple-objc becomes $ dwarfdump --debug-info --apple-objc Differential Revision: https://reviews.llvm.org/D37714 llvm-svn: 312970
* Canonicalize the representation of empty an expression in ↵Adrian Prantl2017-08-305-9/+9
| | | | | | | | | | | | | | | | DIGlobalVariableExpression This change simplifies code that has to deal with DIGlobalVariableExpression and mirrors how we treat DIExpressions in debug info intrinsics. Before this change there were two ways of representing empty expressions on globals, a nullptr and an empty !DIExpression(). If someone needs to upgrade out-of-tree testcases: perl -pi -e 's/(!DIGlobalVariableExpression\(var: ![0-9]*)\)/\1, expr: !DIExpression())/g' <MYTEST.ll> will catch 95%. llvm-svn: 312144
* [IR] AutoUpgrade ModuleFlagBehavior for PIC and PIE levelSteven Wu2017-08-211-2/+2
| | | | | | | | | | | | | | | | | | | Summary: From r303590, ModuleFlagBehavior for PIC and PIE level is changed from Error to Max. This will cause bitcode compatibility issue when linking against a bitcode static archive built with old compiler. Add an auto-ugprade path to upgrade the the ModuleFlagBehavior in the old bitcode to match the new one so IRLinker can link them. Reviewers: tejohnson, mehdi_amini, dexonsmith Reviewed By: dexonsmith Subscribers: hans, llvm-commits Differential Revision: https://reviews.llvm.org/D36556 llvm-svn: 311387
* [DI] Every DIGlobalVariable should have a type.Davide Italiano2017-08-161-2/+2
| | | | | | | I'll make this a verifier check to catch other violations. This commit fixes the tests already in tree. llvm-svn: 311004
* [Linker] PR33527 - Linker::LinkOnlyNeeded should import AppendingLinkage globalsBenoit Belley2017-08-0910-0/+164
| | | | | | | | | | | Linker::LinkOnlyNeeded should always import globals with AppendingLinkage. This resolves PR33527. Differential Revision: https://reviews.llvm.org/D34448 llvm-svn: 310522
* ThinLTO: Don't import aliases of any kind (even linkonce_odr)David Blaikie2017-07-271-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Until a more advanced version of importing can be implemented for aliases (one that imports an alias as an available_externally definition of the aliasee), skip the narrow subset of cases that was possible but came at a cost: aliases of linkonce_odr functions could be imported because the linkonce_odr function could be safely duplicated from the source module. This came/comes at the cost of not being able to 'home' imported linkonce functions (they had to be emitted linkonce_odr in all the destination modules (even if they weren't used by an alias) rather than as available_externally - causing extra object size). Tangentially, this also was the only reason ThinLTO would emit multiple CUs in to the resulting DWARF - which happens to be a problem for Fission (there's a fix for this in GDB but not released yet, etc). (actually it's not the only reason - but I'm sending a patch to fix the other reason shortly) There's no reason to believe this particularly narrow alias importing was especially/meaningfully important, only that it was /possible/ to implement in this way. When a more general solution is done, it should still satisfy the DWARF concerns above, since the import will still be available_externally, and thus not create extra CUs. Since now all aliases are treated the same, I removed/simplified some test cases since they were testing corner cases where there are no longer any corners. Reviewers: tejohnson, mehdi_amini Differential Revision: https://reviews.llvm.org/D35875 llvm-svn: 309278
* Debug Info: Add a file: field to DIImportedEntity.Adrian Prantl2017-07-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | DIImportedEntity has a line number, but not a file field. To determine the decl_line/decl_file we combine the line number from the DIImportedEntity with the file from the DIImportedEntity's scope. This does not work correctly when the parent scope is a DINamespace or a DIModule, both of which do not have a source file. This patch adds a file field to DIImportedEntity to unambiguously identify the source location of the using/import declaration. Most testcase updates are mechanical, the interesting one is the removal of the FIXME in test/DebugInfo/Generic/namespace.ll. This fixes PR33822. See https://bugs.llvm.org/show_bug.cgi?id=33822 for more context. <rdar://problem/33357889> https://bugs.llvm.org/show_bug.cgi?id=33822 Differential Revision: https://reviews.llvm.org/D35583 llvm-svn: 308398
* [Linker] Add directives to support mixing ARM/Thumb module-level inline asm.Florian Hahn2017-07-122-0/+23
| | | | | | | | | | | | | | | | | | | | | | Summary: By prepending `.text .thumb .balign 2` to the module-level inline assembly from a Thumb module, the assembler will generate the assembly from that module as Thumb, even if the destination module uses an ARM triple. Similar directives are used for module-level inline assembly in ARM modules. The alignment and instruction set are reset based on the target triple before emitting the first function label. Reviewers: olista01, tejohnson, echristo, t.p.northover, rafael Reviewed By: echristo Subscribers: aemerson, javed.absar, eraman, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D34622 llvm-svn: 307772
* Enhance synchscope representationKonstantin Zhuravlyov2017-07-113-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
* [Linker] Remove llc usage from link-arm-and-thumb.ll test case.Florian Hahn2017-06-071-9/+6
| | | | | | This fixes a buildbot failure when the ARM target is not built. llvm-svn: 304888
* [Linker] Remove warning when linking ARM and Thumb IR modules.Florian Hahn2017-06-072-0/+42
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch updates Triple::isCompatibleWith to make armxx and thumbxx triples compatible, as long as the subarch, vendor, os, envorionment and object format match. Thumb/ARM code generation should be controlled using the thumb-mode per-function target feature rather than by the triple to allow mixing Thumb and ARM functions. D33448 updates Clang's codegen to add thumb-mode for all functions with armxx or thumbxx triples. Reviewers: echristo, t.p.northover, rafael, kristof.beyls, rengolin, tejohnson Reviewed By: tejohnson Subscribers: rinon, eugenis, pcc, srhines, aemerson, mehdi_amini, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D33287 llvm-svn: 304884
* Support for taking the max of module flags when linking, use for PIE/PICTeresa Johnson2017-05-232-8/+10
| | | | | | | | | | | | | | | | | | | | | | Summary: Add Max ModFlagBehavior, which can be used to take the max of two module flag values when merging modules. Use it for the PIE and PIC levels. This avoids an error when we try to import from a module built -fpic into a module built -fPIC, for example. For both PIE and PIC levels, this will be legal, since the code generation gets more conservative as the level is increased. Therefore we can take the max instead of somehow trying to block importing between modules compiled with different levels. Reviewers: tmsriram, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33418 llvm-svn: 303590
* Remap metadata attached to global variables.Evgeniy Stepanov2017-05-041-0/+11
| | | | | | | Fix for PR32577. Global variables may have !associated metadata, which includes a reference to another global. It needs remapping. llvm-svn: 302203
* Remove line and file from DINamespace.Adrian Prantl2017-04-283-3/+3
| | | | | | | | | | | | | | Fixes the issue highlighted in http://lists.llvm.org/pipermail/cfe-dev/2014-June/037500.html. The DW_AT_decl_file and DW_AT_decl_line attributes on namespaces can prevent LLVM from uniquing types that are in the same namespace. They also don't carry any meaningful information. rdar://problem/17484998 Differential Revision: https://reviews.llvm.org/D32648 llvm-svn: 301706
* [Linker] Provide callback for internalizationJonas Devlieghere2017-03-132-0/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D30738 llvm-svn: 297649
* Verifier: Disallow a line number without a file in DISubprogramJustin Bogner2017-02-171-1/+1
| | | | | | | | A line number doesn't make much sense if you don't say where it's from. Add a verifier check for this and update some tests that had bogus debug info. llvm-svn: 295516
* Linker: Move special casing for available_externally in IRMover to clients. ↵Peter Collingbourne2017-02-021-0/+2
| | | | | | | | | | NFCI. The goal is to simplify the semantic model for clients of IRMover. Differential Revision: https://reviews.llvm.org/D29435 llvm-svn: 293864
* Renumber testcase metadata nodes after r290153.Adrian Prantl2016-12-224-78/+101
| | | | | | | | | | | | | This patch renumbers the metadata nodes in debug info testcases after https://reviews.llvm.org/D26769. This is a separate patch because it causes so much churn. This was implemented with a python script that pipes the testcases through llvm-as - | llvm-dis - and then goes through the original and new output side-by side to insert all comments at a close-enough location. Differential Revision: https://reviews.llvm.org/D27765 llvm-svn: 290292
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-205-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-165-15/+11
| | | | | | | | | | | | | | | | | This reverts commit 289920 (again). I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable has not DIExpression. Unfortunately it is not possible to safely upgrade these variables without adding a flag to the bitcode record indicating which version they are. My plan of record is to roll the planned follow-up patch that adds a unit: field to DIGlobalVariable into this patch before recomitting. This way we only need one Bitcode upgrade for both changes (with a version flag in the bitcode record to safely distinguish the record formats). Sorry for the churn! llvm-svn: 289982
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-165-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289920
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-165-15/+11
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-165-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289902
* [ThinLTO] Stop importing constant global vars as copies in the backendTeresa Johnson2016-12-021-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We were doing an optimization in the ThinLTO backends of importing constant unnamed_addr globals unconditionally as a local copy (regardless of whether the thin link decided to import them). This should be done in the thin link instead, so that resulting exported references are marked and promoted appropriately, but will need a summary enhancement to mark these variables as constant unnamed_addr. The function import logic during the thin link was trying to handle this proactively, by conservatively marking all values referenced in the initializer lists of exported global variables as also exported. However, this only handled values referenced directly from the initializer list of an exported global variable. If the value is itself a constant unnamed_addr variable, we could end up exporting its references as well. This caused multiple issues. The first is that the transitively exported references weren't promoted. Secondly, some could not be promoted/renamed (e.g. they had a section or other constraint). recursively, instead of just adding the first level of initializer list references to the ExportList directly. Remove this optimization and the associated handling in the function import backend. SPEC measurements indicate we weren't getting much from it in any case. Fixes PR31052. Reviewers: mehdi_amini Subscribers: krasin, llvm-commits Differential Revision: https://reviews.llvm.org/D26880 llvm-svn: 288446
* Linker: Remove unnecessary call to copyMetadata in IRLinker::linkGlobalVariable.Peter Collingbourne2016-11-143-4/+76
| | | | | | | | | | | This was causing us to create duplicate metadata on global variables. Debug info test case by Adrian Prantl, additional test cases by me. Fixes PR31012. Differential Revision: https://reviews.llvm.org/D26622 llvm-svn: 286905
* Fix autoupgrade logic for Objective-C class properties module flagMehdi Amini2016-09-162-0/+21
| | | | | | | | | | | | | | Previous we were issuing an error when linking a module containing the new Objective-C metadata structure for class properties with an "old" one. Now instead we downgrade the module flag so that the Objective-C runtime does not expect the new metadata structure. This is consistent with what ld64 is doing on binary files. Differential Revision: https://reviews.llvm.org/D24620 llvm-svn: 281685
* DebugInfo: New metadata representation for global variables.Peter Collingbourne2016-09-134-14/+15
| | | | | | | | | | | | | This patch reverses the edge from DIGlobalVariable to GlobalVariable. This will allow us to more easily preserve debug info metadata when manipulating global variables. Fixes PR30362. A program for upgrading test cases is attached to that bug. Differential Revision: http://reviews.llvm.org/D20147 llvm-svn: 281284
OpenPOWER on IntegriCloud