aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/AsmParser
AgeCommit message (Collapse)AuthorFilesLines
2016-09-13DebugInfo: New metadata representation for global variables.Peter Collingbourne1-2/+2
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
2016-09-06DebugInfo: use strongly typed enum for debug info flagsLeny Kholodov1-9/+12
Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes: Get rid of unsigned int for flags to avoid problems on platforms with sizeof(int) < 4 Flags are now strongly typed Patch by: Victor Leschuk <vleschuk@gmail.com> Differential Revision: https://reviews.llvm.org/D23766 llvm-svn: 280700
2016-09-06Revert "DebugInfo: use strongly typed enum for debug info flags"Mehdi Amini1-12/+9
This reverts commit r280686, bots are broken. llvm-svn: 280688
2016-09-06DebugInfo: use strongly typed enum for debug info flagsMehdi Amini1-9/+12
Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes: * Get rid of unsigned int for flags to avoid problems on platforms with sizeof(int) < 4 * Flags are now strongly typed Patch by: Victor Leschuk <vleschuk@gmail.com> Differential Revision: https://reviews.llvm.org/D23766 llvm-svn: 280686
2016-08-26[AsmParser] Placate a -Wmisleading-indentantion warning (GCC7).Davide Italiano1-1/+3
llvm-svn: 279848
2016-08-25Fix some Clang-tidy modernize-use-using and Include What You Use warnings; ↵Eugene Zelenko1-23/+41
other minor fixes. Differential revision: https://reviews.llvm.org/D23861 llvm-svn: 279695
2016-08-24DebugInfo: Add flag to CU to disable emission of inline debug info into the ↵David Blaikie1-2/+4
skeleton CU In cases where .dwo/.dwp files are guaranteed to be available, skipping the extra online (in the .o file) inline info can save a substantial amount of space - see the original r221306 for more details there. llvm-svn: 279650
2016-08-18[LLVM] Fix some Clang-tidy modernize-use-using and Include What You Use warningsEugene Zelenko1-17/+18
Differential revision: https://reviews.llvm.org/D23675 llvm-svn: 279102
2016-08-11Use range algorithms instead of unpacking begin/endDavid Majnemer1-1/+1
No functionality change is intended. llvm-svn: 278417
2016-08-05LLLexer.cpp: Avoid using BitsToDouble() to preserve SNaN like "double ↵NAKAMURA Takumi1-1/+2
0x7FF4000000000000". We should not use double (or float) in the LLVM, unless it is really needed. x87 FP register doesn't preserve SNaN to move the value. FIXME: APFloat() may have the constructor by raw bit. llvm-svn: 277813
2016-08-05Reformat.NAKAMURA Takumi1-1/+1
llvm-svn: 277812
2016-07-04Add writeonly IR attributeNicolai Haehnle3-0/+4
Summary: This complements the earlier addition of IntrWriteMem and IntrWriteArgMem LLVM intrinsic properties, see D18291. Also start using the attribute for memset, memcpy, and memmove intrinsics, and remove their special-casing in BasicAliasAnalysis. Reviewers: reames, joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18714 llvm-svn: 274485
2016-07-01[codeview] Add DISubprogram::ThisAdjustmentReid Kleckner1-3/+5
Summary: This represents the adjustment applied to the implicit 'this' parameter in the prologue of a virtual method in the MS C++ ABI. The adjustment is always zero unless multiple inheritance is involved. This increases the size of DISubprogram by 8 bytes, unfortunately. The adjustment really is a signed 32-bit integer. If this size increase is too much, we could probably win it back by splitting out a subclass with info specific to virtual methods (virtuality, vindex, thisadjustment, containingType). Reviewers: aprantl, dexonsmith Subscribers: aaboud, amccarth, llvm-commits Differential Revision: http://reviews.llvm.org/D21614 llvm-svn: 274325
2016-06-24Remangle intrinsics names when types are renamedArtur Pilipenko1-0/+13
This is a resubmittion of previously reverted rL273568. This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html Reviewers: mehdi_amini, reames Differential Revision: http://reviews.llvm.org/D19373 llvm-svn: 273686
2016-06-23Revert r273568 "Remangle intrinsics names when types are renamed"Hans Wennborg1-13/+0
It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll llvm-svn: 273574
2016-06-23Remangle intrinsics names when types are renamedArtur Pilipenko1-0/+13
This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html Reviewers: mehdi_amini, reames Differential Revision: http://reviews.llvm.org/D19373 llvm-svn: 273568
2016-06-21IR: Allow metadata attachments on declarations, and fix lazy loaded metadata ↵Peter Collingbourne1-1/+14
issue with globals. This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336
2016-06-14IR: Introduce local_unnamed_addr attribute.Peter Collingbourne4-18/+28
If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-08[DebugInfo] Add calling convention support for DWARF and CodeViewReid Kleckner3-1/+26
Summary: Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If it is present and non-zero, the backend will emit it as a DW_AT_calling_convention attribute. On the CodeView side, we translate it to the appropriate enum for the LF_PROCEDURE record. I added a new LLVM vendor specific enum to the list of DWARF calling conventions. DWARF does not appear to attempt to standardize these, so I assume it's OK to do this until we coordinate with GCC on how to emit vectorcall convention functions. Reviewers: dexonsmith, majnemer, aaboud, amccarth Subscribers: mehdi_amini, llvm-commits Differential Revision: http://reviews.llvm.org/D21114 llvm-svn: 272197
2016-06-02[ASMParser] Parse FP constants in non-C localesMeador Inge1-2/+4
This patch fixes PR25788, which allows for the parsing of floating-point constants in non-C locales. Patch by Antoine Pitrou! Differential Revision: http://reviews.llvm.org/D15375 llvm-svn: 271574
2016-06-01IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne1-1/+1
This will be necessary to allow the global merge pass to attach multiple debug info metadata nodes to global variables once we reverse the edge from DIGlobalVariable to GlobalVariable. Differential Revision: http://reviews.llvm.org/D20414 llvm-svn: 271358
2016-05-31Add support for metadata attachments for global variables.Peter Collingbourne2-7/+18
This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
2016-05-29Remove some 'const' specifiers that do nothing but prevent moving the argument.Benjamin Kramer1-1/+1
Found by clang-tidy's misc-move-const-arg. While there drop some obsolete c_str() calls. llvm-svn: 271181
2016-05-25Objective-C Class Properties: Autoupgrade "Class Properties" module flag.Manman Ren1-0/+2
When we have "Image Info Version" module flag but don't have "Class Properties" module flag, set "Class Properties" module flag to 0, so we can correctly emit errors when one module has the flag set and another module does not. rdar://26469641 llvm-svn: 270791
2016-05-12Refactor duplicated code. NFC.Rafael Espindola2-33/+39
Linkage is always followed by visibility and dll storage. llvm-svn: 269286
2016-05-11Refactor duplicated check for valid declaration linkage. NFC.Rafael Espindola1-2/+3
llvm-svn: 269184
2016-05-11clang-format LLToken.h.Rafael Espindola1-225/+339
Having it be special is quite annoying for being able to just run git-clang-format in patches that change it. llvm-svn: 269175
2016-05-10Make "@name =" mandatory for globals in .ll files.Rafael Espindola1-40/+0
An oddity of the .ll syntax is that the "@var = " in @var = global i32 42 is optional. Writing just global i32 42 is equivalent to @0 = global i32 42 This means that there is a pretty big First set at the top level. The current implementation maintains it manually. I was trying to refactor it, but then started wondering why keep it a all. I personally find the above syntax confusing. It looks like something is missing. This patch removes the feature and simplifies the parser. llvm-svn: 269096
2016-05-10Simplify LLParser::ParseOptionalLinkage. NFC.Rafael Espindola1-19/+34
llvm-svn: 269080
2016-05-06AMDGPU/SI: Add amdgpu_kernel calling convention. Part 1.Nikolay Haustov3-0/+4
Summary: This will be used for AMDGPU_HSA_KERNEL symbol type in output ELF. Also, in the future unused non-kernels may be optimized. For now, also accept SPIR_KERNEL for HCC frontend. Also, add bitcode compatibility tests for missing calling conventions except AVR_BUILTIN which doesn't have parse code. Reviewers: tstellarAMD, arsenm Subscribers: arsenm, joker.eph, llvm-commits llvm-svn: 268717
2016-04-19IR: Enable debug info type ODR uniquing for forward declsDuncan P. N. Exon Smith1-4/+3
Add a new method, DICompositeType::buildODRType, that will create or mutate the DICompositeType for a given ODR identifier, and use it in LLParser and BitcodeReader instead of DICompositeType::getODRType. The logic is as follows: - If there's no node, create one with the given arguments. - Else, if the current node is a forward declaration and the new arguments would create a definition, mutate the node to match the new arguments. - Else, return the old node. This adds a missing feature supported by the current DITypeIdentifierMap (which I'm slowly making redudant). The only remaining difference is that the DITypeIdentifierMap has a "the-last-one-wins" rule, whereas DICompositeType::buildODRType has a "the-first-one-wins" rule. For now I'm leaving behind DICompositeType::getODRType since it has obvious, low-level semantics that are convenient for unit testing. llvm-svn: 266786
2016-04-19IR: getOrInsertODRUniquedType => DICompositeType::getODRType, NFCDuncan P. N. Exon Smith1-9/+9
Lift the API for debug info ODR type uniquing up a layer. Instead of clients managing the map directly on the LLVMContext, add a static method to DICompositeType called getODRType and handle the map in the background. Also adds DICompositeType::getODRTypeIfExists, so far just for convenience in the unit tests. This simplifies the logic in LLParser and BitcodeReader. Because of argument spam there are actually a few more lines of code now; I'll see if I come up with a reasonable way to clean that up. llvm-svn: 266742
2016-04-19IR: Require DICompositeType for ODR uniquing type mapDuncan P. N. Exon Smith1-2/+2
Tighten up the API for debug info ODR type uniquing in LLVMContext. The only reason to allow other DIType subclasses is to make the unit tests prettier :/. llvm-svn: 266737
2016-04-19IR: Rename API for enabling ODR uniquing of DITypes, NFCDuncan P. N. Exon Smith1-1/+1
As per David's review, rename everything in the new API for ODR type uniquing of debug info. ensureDITypeMap => enableDebugTypeODRUniquing destroyDITypeMap => disableDebugTypeODRUniquing hasDITypeMap => isODRUniquingDebugTypes llvm-svn: 266713
2016-04-18[NFC] Header cleanupMehdi Amini1-1/+0
Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
2016-04-17IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith1-0/+14
Rather than relying on the structural equivalence of DICompositeType to merge type definitions, use an explicit map on the LLVMContext that LLParser and BitcodeReader consult when constructing new nodes. Each non-forward-declaration DICompositeType with a non-empty 'identifier:' field is stored/loaded from the type map, and the first definiton will "win". This map is opt-in: clients that expect ODR types from different modules to be merged must call LLVMContext::ensureDITypeMap. - Clients that just happen to load more than one Module in the same LLVMContext won't magically merge types. - Clients (like LTO) that want to continue to merge types based on ODR identifiers should opt-in immediately. I have updated LTOCodeGenerator.cpp, the two "linking" spots in gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to set this. With this in place, it will be straightforward to remove the DITypeRef concept (i.e., referencing types by their 'identifier:' string rather than pointing at them directly). llvm-svn: 266549
2016-04-16Update and fix LLVM_ENABLE_MODULES:Richard Smith1-1/+0
1) We need to add this flag prior to adding any other, in case the user has specified a -fmodule-cache-path= flag in their custom CXXFLAGS. Such a flag causes -Werror builds to fail, and thus all config checks fail, until we add the corresponding -fmodules flag. The modules selfhost bot does this, for instance. 2) Delete module maps that were putting .cpp files into modules. 3) Enable -fmodules-local-submodule-visibility, to get proper module visibility rules applied across submodules of the same module. Disable -fmodules for C builds, since that flag is not available there. llvm-svn: 266502
2016-04-15[PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Adrian Prantl1-10/+8
Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-12Add the allocsize attribute to LLVM.George Burgess IV4-1/+46
`allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-07[GCC] Attribute ifunc support in llvmDmitry Polukhin3-11/+17
This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. Patch for Clang http://reviews.llvm.org/D15524 Differential Revision: http://reviews.llvm.org/D15525 llvm-svn: 265667
2016-04-06NFC: make AtomicOrdering an enum classJF Bastien1-22/+32
Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
2016-04-06AMDGPU: Add a shader calling conventionNicolai Haehnle3-0/+18
This makes it possible to distinguish between mesa shaders and other kernels even in the presence of compute shaders. Patch By: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Differential Revision: http://reviews.llvm.org/D18559 llvm-svn: 265589
2016-04-06AsmParser: Don't crash on unresolved !tbaaDuncan P. N. Exon Smith1-4/+5
Instead of crashing, give a nice error. As a drive-by, fix the location associated with the errors for unresolved metadata (the location was off by one token). llvm-svn: 265507
2016-04-05Swift Calling Convention: add swiftcc.Manman Ren3-0/+4
Differential Revision: http://reviews.llvm.org/D17863 llvm-svn: 265480
2016-04-05[IFUNC] Use GlobalIndirectSymbol when aliases and ifuncs have something similarDmitry Polukhin2-21/+41
Second part extracted from http://reviews.llvm.org/D15525 Use GlobalIndirectSymbol in all cases when aliases and ifuncs have something in common. Differential Revision: http://reviews.llvm.org/D18754 llvm-svn: 265382
2016-04-02Rename Context::discardValueNames() to shouldDiscardValueNames() (NFC)Mehdi Amini1-1/+1
Suggested by Sean Silva. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265211
2016-04-01Swift Calling Convention: add swifterror attribute.Manman Ren3-1/+9
A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst. This commit does not include any target-specific change. The target-specific optimization will come as a follow-up patch. Differential Revision: http://reviews.llvm.org/D18092 llvm-svn: 265189
2016-03-31Move the DebugEmissionKind enum from DIBuilder into DICompileUnit.Adrian Prantl3-3/+30
This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder into DICompileUnit. DIBuilder is not the right place for this enum to live in — a metadata consumer should not have to include DIBuilder.h. I also added a Verifier check that checks that the emission kind of a DICompileUnit is actually legal. http://reviews.llvm.org/D18612 <rdar://problem/25427165> llvm-svn: 265077
2016-03-30Restore "[ThinLTO] Serialize the Module SourceFileName to/from LLVM assembly"Teresa Johnson4-0/+20
This restores commit 264869, with a fix for windows bots to properly escape '\' in the path when serializing out. Added test. llvm-svn: 264884
2016-03-30Revert "[ThinLTO] Serialize the Module SourceFileName to/from LLVM assembly"Teresa Johnson4-20/+0
This reverts commit r264869. I am seeing Windows bot failures due to the "\" in the path being mishandled at some point (seems to be interpreted wrongly at some point and llvm-as | llvm-dis is yielding some junk characters). Need to investigate. llvm-svn: 264871
generated by cgit v1.1 at 2025-10-14 16:43:09 +0000