summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Verifier.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Verifier] Remove the -verify-debug-info cl::optVedant Kumar2017-11-021-2/+0
| | | | | | | This cl::opt has been dead for a while. It's no longer possible to run the verifier without also verifying debug info. llvm-svn: 317288
* Create instruction classes for identifying any atomicity of memory ↵Daniel Neilson2017-10-301-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | intrinsic. (NFC) Summary: For reference, see: http://lists.llvm.org/pipermail/llvm-dev/2017-August/116589.html This patch fleshes out the instruction class hierarchy with respect to atomic and non-atomic memory intrinsics. With this change, the relevant part of the class hierarchy becomes: IntrinsicInst -> MemIntrinsicBase (methods-only class) -> MemIntrinsic (non-atomic intrinsics) -> MemSetInst -> MemTransferInst -> MemCpyInst -> MemMoveInst -> AtomicMemIntrinsic (atomic intrinsics) -> AtomicMemSetInst -> AtomicMemTransferInst -> AtomicMemCpyInst -> AtomicMemMoveInst -> AnyMemIntrinsic (both atomicities) -> AnyMemSetInst -> AnyMemTransferInst -> AnyMemCpyInst -> AnyMemMoveInst This involves some class renaming: ElementUnorderedAtomicMemCpyInst -> AtomicMemCpyInst ElementUnorderedAtomicMemMoveInst -> AtomicMemMoveInst ElementUnorderedAtomicMemSetInst -> AtomicMemSetInst A script for doing this renaming in downstream trees is included below. An example of where the Any* classes should be used in LLVM is when reasoning about the effects of an instruction (ex: aliasing). --- Script for renaming AtomicMem* classes: PREFIXES="[<,([:space:]]" CLASSES="MemIntrinsic|MemTransferInst|MemSetInst|MemMoveInst|MemCpyInst" SUFFIXES="[;)>,[:space:]]" REGEX="(${PREFIXES})ElementUnorderedAtomic(${CLASSES})(${SUFFIXES})" REGEX2="visitElementUnorderedAtomic(${CLASSES})" FILES=$( grep -E "(${REGEX}|${REGEX2})" -r . | tr ':' ' ' | awk '{print $1}' | sort | uniq ) SED_SCRIPT="s~${REGEX}~\1Atomic\2\3~g" SED_SCRIPT2="s~${REGEX2}~visitAtomic\1~g" for f in $FILES; do echo "Processing: $f" sed -i ".bak" -E "${SED_SCRIPT};${SED_SCRIPT2};${EA_SED_SCRIPT};${EA_SED_SCRIPT2}" $f done Reviewers: sanjoy, deadalnix, apilipenko, anna, skatkov, mkazantsev Reviewed By: sanjoy Subscribers: hfinkel, jholewinski, arsenm, sdardis, nhaehnle, JDevlieghere, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D38419 llvm-svn: 316950
* Represent runtime preemption in the IR.Sean Fertile2017-10-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we do not represent runtime preemption in the IR, which has several drawbacks: 1) The semantics of GlobalValues differ depending on the object file format you are targeting (as well as the relocation-model and -fPIE value). 2) We have no way of disabling inlining of run time interposable functions, since in the IR we only know if a function is link-time interposable. Because of this llvm cannot support elf-interposition semantics. 3) In LTO builds of executables we will have extra knowledge that a symbol resolved to a local definition and can't be preemptable, but have no way to propagate that knowledge through the compiler. This patch adds preemptability specifiers to the IR with the following meaning: dso_local --> means the compiler may assume the symbol will resolve to a definition within the current linkage unit and the symbol may be accessed directly even if the definition is not within this compilation unit. dso_preemptable --> means that the compiler must assume the GlobalValue may be replaced with a definition from outside the current linkage unit at runtime. To ease transitioning dso_preemptable is treated as a 'default' in that low-level codegen will still do the same checks it did previously to see if a symbol should be accessed indirectly. Eventually when IR producers emit the specifiers on all Globalvalues we can change dso_preemptable to mean 'always access indirectly', and remove the current logic. Differential Revision: https://reviews.llvm.org/D20217 llvm-svn: 316668
* Verifier: Ignore CUs pulled in by ODR-uniqued types.Adrian Prantl2017-10-181-0/+5
| | | | | | | | | | | | | | | 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-181-6/+0
| | | | | | This reverts commit r316049. llvm-svn: 316050
* Verifier: Ignore CUs pulled in by ODR-uniqued types.Adrian Prantl2017-10-181-0/+6
| | | | | | | | | | | | | 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
* Move the stripping of invalid debug info from the Verifier to AutoUpgrade.Adrian Prantl2017-10-021-25/+4
| | | | | | | | | | | | | | | | | | | | | | | | This came out of a recent discussion on llvm-dev (https://reviews.llvm.org/D38042). Currently the Verifier will strip the debug info metadata from a module if it finds the dbeug info to be malformed. This feature is very valuable since it allows us to improve the Verifier by making it stricter without breaking bcompatibility, but arguable the Verifier pass should not be modifying the IR. This patch moves the stripping of broken debug info into AutoUpgrade (UpgradeDebugInfo to be precise), which is a much better location for this since the stripping of malformed (i.e., produced by older, buggy versions of Clang) is a (harsh) form of AutoUpgrade. This change is mostly NFC in nature, the one big difference is the behavior when LLVM module passes are introducing malformed debug info. Prior to this patch, a NoAsserts build would have printed a warning and stripped the debug info, after this patch the Verifier will report a fatal error. I believe this behavior is actually more desirable anyway. Differential Revision: https://reviews.llvm.org/D38184 llvm-svn: 314699
* [Verifier] Stop accepting broken DIGlobalVariable(s).Davide Italiano2017-09-241-1/+3
| | | | | | | | The code wasn't yelling at the user when there's a reference from a DIGlobalVariableExpression. Thanks to Adrian for the reduced testcase. Fixes PR34672. llvm-svn: 314069
* Fix uninteneded fallthrough detected by GCC warningReid Kleckner2017-09-221-0/+1
| | | | llvm-svn: 314043
* Re-land r313825: "[IR] Add llvm.dbg.addr, a control-dependent version of ↵Reid Kleckner2017-09-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | llvm.dbg.declare" The fix is to avoid invalidating our insertion point in replaceDbgDeclare: Builder.insertDeclare(NewAddress, DIVar, DIExpr, Loc, InsertBefore); + if (DII == InsertBefore) + InsertBefore = &*std::next(InsertBefore->getIterator()); DII->eraseFromParent(); I had to write a unit tests for this instead of a lit test because the use list order matters in order to trigger the bug. The reduced C test case for this was: void useit(int*); static inline void inlineme() { int x[2]; useit(x); } void f() { inlineme(); inlineme(); } llvm-svn: 313905
* Revert r313825: "[IR] Add llvm.dbg.addr, a control-dependent version of ↵Daniel Jasper2017-09-211-2/+0
| | | | | | | | | | | llvm.dbg.declare" .. as well as the two subsequent changes r313826 and r313875. This leads to segfaults in combination with ASAN. Will forward repro instructions to the original author (rnk). llvm-svn: 313876
* [IR] Add llvm.dbg.addr, a control-dependent version of llvm.dbg.declareReid Kleckner2017-09-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This implements the design discussed on llvm-dev for better tracking of variables that live in memory through optimizations: http://lists.llvm.org/pipermail/llvm-dev/2017-September/117222.html This is tracked as PR34136 llvm.dbg.addr is intended to be produced and used in almost precisely the same way as llvm.dbg.declare is today, with the exception that it is control-dependent. That means that dbg.addr should always have a position in the instruction stream, and it will allow passes that optimize memory operations on local variables to insert llvm.dbg.value calls to reflect deleted stores. See SourceLevelDebugging.rst for more details. The main drawback to generating DBG_VALUE machine instrs is that they usually cause LLVM to emit a location list for DW_AT_location. The next step will be to teach DwarfDebug.cpp how to recognize more DBG_VALUE ranges as not needing a location list, and possibly start setting DW_AT_start_offset for variables whose lifetimes begin mid-scope. Reviewers: aprantl, dblaikie, probinson Subscribers: eraman, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D37768 llvm-svn: 313825
* Move duplicate helpers from DbgValueInst / DbgDeclareInst to DbgInfoIntrinsicReid Kleckner2017-09-071-28/+11
| | | | | | NFC llvm-svn: 312754
* Revert "Revert r312139 "Verifier: Verify the correctness of fragment ↵Adrian Prantl2017-08-311-8/+22
| | | | | | | | expressions attached to globals."" This reverts commit r312182 after fixing PR34390. llvm-svn: 312197
* Revert r312139 "Verifier: Verify the correctness of fragment expressions ↵Hans Wennborg2017-08-301-22/+8
| | | | | | | | attached to globals." This caused PR34390. llvm-svn: 312182
* Verifier: Verify the correctness of fragment expressions attached to globals.Adrian Prantl2017-08-301-8/+22
| | | | llvm-svn: 312139
* [Verifier] Diagnose invalid DIType references instead of crashing.Davide Italiano2017-08-251-0/+1
| | | | | | Fixes PR34325. llvm-svn: 311805
* Add ‘llvm.experimental.constrained.fma‘ Intrinsic.Wei Ding2017-08-241-2/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D36335 llvm-svn: 311629
* Retire the llvm.dbg.mir hack after r311594.Adrian Prantl2017-08-231-1/+1
| | | | llvm-svn: 311610
* Add a Verifier check for DILocation's scopes.Adrian Prantl2017-08-231-0/+4
| | | | | | Found via https://bugs.llvm.org/show_bug.cgi?id=33997. llvm-svn: 311608
* [Verifier] Avoid visiting DIGlobalVariables twice.Davide Italiano2017-08-171-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | We currently visit them twice. Once, through `visitMDNode()` -> (the code generated by) `../include/llvm/IR/Metadata.def:109` -> `visitDIGlobalVariable()` Then, through `visitMDNode()` -> `visitDIGlobalVariableExpression()` -> `visitDIGlobalVariable()` This results in verification failures printed twice, e.g.: $ ./opt -verify ../../test/DebugInfo/pr34186.ll missing global variable type !4 = distinct !DIGlobalVariable(name: "pat", scope: !0, file: !1, line: 27, isLocal: true, isDefinition: true) missing global variable type !4 = distinct !DIGlobalVariable(name: "pat", scope: !0, file: !1, line: 27, isLocal: true, isDefinition: true) ./opt: ../../test/DebugInfo/pr34186.ll: error: input module is broken! The patch removes one call so we ensure each GV is visited exactly once. Differential Revision: https://reviews.llvm.org/D36797 llvm-svn: 311081
* [Verifier] Reject globals without a type associated.Davide Italiano2017-08-161-0/+1
| | | | llvm-svn: 311012
* Add strictfp attribute to prevent unwanted optimizations of libm callsAndrew Kaylor2017-08-141-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D34163 llvm-svn: 310885
* Remove PrologEpilogInserter's usage of DBG_VALUE's offset fieldAdrian Prantl2017-08-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the last half-dozen commits to LLVM I removed code that became dead after removing the offset parameter from llvm.dbg.value gradually proceeding from IR towards the backend. Before I can move on to DwarfDebug and friends there is one last side-called offset I need to remove: This patch modifies PrologEpilogInserter's use of the DBG_VALUE's offset argument to use a DIExpression instead. Because the PrologEpilogInserter runs at the Machine level I had to play a little trick with a named llvm.dbg.mir node to get the DIExpressions to print in MIR dumps (which print the llvm::Module followed by the MachineFunction dump). I also had to add rudimentary DwarfExpression support to CodeView and as a side-effect also fixed a bug (CodeViewDebug::collectVariableInfo was supposed to give up on variables with complex DIExpressions, but would fail to do so for fragments, which are also modeled as DIExpressions). With this last holdover removed we will have only one canonical way of representing offsets to debug locations which will simplify the code in DwarfDebug (and future versions of CodeViewDebug once it starts handling more complex expressions) and make it easier to reason about. This patch is NFC-ish: All test case changes are for assembler comments and the binary output does not change. rdar://problem/33580047 Differential Revision: https://reviews.llvm.org/D36125 llvm-svn: 309751
* Add element atomic memset intrinsicDaniel Neilson2017-07-121-1/+32
| | | | | | | | | | | | | | Summary: Continuing the work from https://reviews.llvm.org/D33240, this change introduces an element unordered-atomic memset intrinsic. This intrinsic is essentially memset with the implementation requirement that all stores used for the assignment are done with unordered-atomic stores of a given element size. Reviewers: eli.friedman, reames, mkazantsev, skatkov Reviewed By: reames Subscribers: jfb, dschuff, sbc100, jgravelle-google, aheejin, efriedma, llvm-commits Differential Revision: https://reviews.llvm.org/D34885 llvm-svn: 307854
* Add element atomic memmove intrinsicDaniel Neilson2017-07-121-0/+36
| | | | | | | | | | | | | | Summary: Continuing the work from https://reviews.llvm.org/D33240, this change introduces an element unordered-atomic memmove intrinsic. This intrinsic is essentially memmove with the implementation requirement that all loads/stores used for the copy are done with unordered-atomic loads/stores of a given element size. Reviewers: eli.friedman, reames, mkazantsev, skatkov Reviewed By: reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34884 llvm-svn: 307796
* Enhance synchscope representationKonstantin Zhuravlyov2017-07-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [IR] Make use of ↵Craig Topper2017-07-091-11/+8
| | | | | | Type::isPtrOrPtrVectorTy/isIntOrIntVectorTy/isFPOrFPVectorTy to shorten code. NFC llvm-svn: 307491
* [IR] Use CmpInst::isFPPredicate/isIntPredicate in a few other places. NFCCraig Topper2017-07-051-4/+2
| | | | llvm-svn: 307224
* [Atomics] Rename and change prototype for atomic memcpy intrinsicDaniel Neilson2017-06-161-10/+21
| | | | | | | | | | | | | | | | | | Summary: Background: http://lists.llvm.org/pipermail/llvm-dev/2017-May/112779.html This change is to alter the prototype for the atomic memcpy intrinsic. The prototype itself is being changed to more closely resemble the semantics and parameters of the llvm.memcpy intrinsic -- to ease later combination of the llvm.memcpy and atomic memcpy intrinsics. Furthermore, the name of the atomic memcpy intrinsic is being changed to make it clear that it is not a generic atomic memcpy, but specifically a memcpy is unordered atomic. Reviewers: reames, sanjoy, efriedma Reviewed By: reames Subscribers: mzolotukhin, anna, llvm-commits, skatkov Differential Revision: https://reviews.llvm.org/D33240 llvm-svn: 305558
* IR: Replace the "Linker Options" module flag with "llvm.linker.options" ↵Peter Collingbourne2017-06-121-0/+8
| | | | | | | | | | named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Add constrained intrinsics for some libm-equivalent operationsAndrew Kaylor2017-05-251-1/+18
| | | | | | Differential revision: https://reviews.llvm.org/D32319 llvm-svn: 303922
* [IR] Switch AttributeList to use an array for O(1) accessReid Kleckner2017-05-231-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
* Support for taking the max of module flags when linking, use for PIE/PICTeresa Johnson2017-05-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | 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
* Fix breakage after r303461Matthias Braun2017-05-201-3/+0
| | | | | | | - Improve wchar_t size predicitions based on target triple. - Be less strict in wchar_t size verifier. llvm-svn: 303477
* Verifier: Check wchar_size module flag.Matthias Braun2017-05-191-0/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D32974 llvm-svn: 303460
* Make it illegal for two Functions to point to the same DISubprogramAdrian Prantl2017-05-091-2/+11
| | | | | | | | | | | | | | | | | | | As recently discussed on llvm-dev [1], this patch makes it illegal for two Functions to point to the same DISubprogram and updates FunctionCloner to also clone the debug info of a function to conform to the new requirement. To simplify the implementation it also factors out the creation of inlineAt locations from the Inliner into a general-purpose utility in DILocation. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112661.html <rdar://problem/31926379> Differential Revision: https://reviews.llvm.org/D32975 This reapplies r302469 with a fix for a bot failure (reparentDebugInfo now checks for the case the orig and new function are identical). llvm-svn: 302576
* Revert r302469 "Make it illegal for two Functions to point to the same ↵Hans Wennborg2017-05-091-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | DISubprogram" This caused PR32977. Original commit message: > Make it illegal for two Functions to point to the same DISubprogram > > As recently discussed on llvm-dev [1], this patch makes it illegal for > two Functions to point to the same DISubprogram and updates > FunctionCloner to also clone the debug info of a function to conform > to the new requirement. To simplify the implementation it also factors > out the creation of inlineAt locations from the Inliner into a > general-purpose utility in DILocation. > > [1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112661.html > <rdar://problem/31926379> > > Differential Revision: https://reviews.llvm.org/D32975 llvm-svn: 302533
* Make it illegal for two Functions to point to the same DISubprogramAdrian Prantl2017-05-081-2/+11
| | | | | | | | | | | | | | | | As recently discussed on llvm-dev [1], this patch makes it illegal for two Functions to point to the same DISubprogram and updates FunctionCloner to also clone the debug info of a function to conform to the new requirement. To simplify the implementation it also factors out the creation of inlineAt locations from the Inliner into a general-purpose utility in DILocation. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112661.html <rdar://problem/31926379> Differential Revision: https://reviews.llvm.org/D32975 llvm-svn: 302469
* AMDGPU: Add AMDGPU_HS calling conventionMarek Olsak2017-05-021-0/+1
| | | | | | | | | | Reviewers: arsenm, nhaehnle Subscribers: mehdi_amini, kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye Differential Revision: https://reviews.llvm.org/D32644 llvm-svn: 301930
* Make getParamAlignment use argument numbersReid Kleckner2017-04-281-3/+3
| | | | | | | | | | | | | | | | | | The method is called "get *Param* Alignment", and is only used for return values exactly once, so it should take argument indices, not attribute indices. Avoids confusing code like: IsSwiftError = CS->paramHasAttr(ArgIdx, Attribute::SwiftError); Alignment = CS->getParamAlignment(ArgIdx + 1); Add getRetAlignment to handle the one case in Value.cpp that wants the return value alignment. This is a potentially breaking change for out-of-tree backends that do their own call lowering. llvm-svn: 301682
* Add speculatable function attributeMatt Arsenault2017-04-281-11/+21
| | | | | | | | This attribute tells the optimizer that the function may be speculated. Patch by Tom Stellard llvm-svn: 301680
* Add support for DW_TAG_thrown_type.Adrian Prantl2017-04-261-0/+8
| | | | | | | | | | | | | | | | | | | | For Swift we would like to be able to encode the error types that a function may throw, so the debugger can display them alongside the function's return value when finish-ing a function. DWARF defines DW_TAG_thrown_type (intended to be used for C++ throw() declarations) that is a perfect fit for this purpose. This patch wires up support for DW_TAG_thrown_type in LLVM by adding a list of thrown types to DISubprogram. To offset the cost of the extra pointer, there is a follow-up patch that turns DISubprogram into a variable-length node. rdar://problem/29481673 Differential Revision: https://reviews.llvm.org/D32559 llvm-svn: 301489
* [IR] Make paramHasAttr to use arg indices instead of attr indicesReid Kleckner2017-04-141-2/+2
| | | | | | | | | This avoids the confusing 'CS.paramHasAttr(ArgNo + 1, Foo)' pattern. Previously we were testing return value attributes with index 0, so I introduced hasReturnAttr() for that use case. llvm-svn: 300367
* Simplify some Verifier attribute checks with AttributeSetReid Kleckner2017-04-141-188/+175
| | | | | | | | | | | Now that we have a type that can represent the attributes on a single return, function, or parameter, we can pass it around directly rather than passing around AttributeList and Idx. Removes some more one-based argument attribute index counting. NFC llvm-svn: 300285
* [IR] Make getParamAttributes take argument numbers, not ArgNo+1Reid Kleckner2017-04-131-3/+3
| | | | | | | | | | | | Add hasParamAttribute() and use it instead of hasAttribute(ArgNo+1, Kind) everywhere. The fact that the AttributeList index for an argument is ArgNo+1 should be a hidden implementation detail. NFC llvm-svn: 300272
* Remove unused functions. Remove static qualifier from functions in header ↵Vassil Vassilev2017-04-111-22/+0
| | | | | | files. NFC. llvm-svn: 299947
* Allow DataLayout to specify addrspace for allocas.Matt Arsenault2017-04-101-2/+3
| | | | | | | | | | | | | | | | | | | | | | | LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888
OpenPOWER on IntegriCloud