summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* LTO type uniquing: store the Decl field of a DIImportedEntity as a DIRef.Adrian Prantl2014-04-012-4/+4
| | | | | | | | | | No other functionality changes, DIBuilder testcase is included in a paired CFE commit. This relaxes the assertion in isScopeRef to also accept subclasses of DIScope. llvm-svn: 205279
* Intrinsics: add LLVMHalfElementsVectorType constraintTim Northover2014-03-292-1/+17
| | | | | | | | | | This is like the LLVMMatchType, except the verifier checks that the second argument is a vector with the same base type and half the number of elements. This will be used by the ARM64 backend. llvm-svn: 205079
* Intrinsics: expand semantics of LLVMExtendedVectorType (& trunc)Tim Northover2014-03-282-22/+48
| | | | | | | | | | | | These are used in the ARM backends to aid type-checking on patterns involving intrinsics. By making sure one argument is an extended/truncated version of another. However, there's no reason to limit them to just vectors types. For example AArch64 has the instruction "uqshrn sD, dN, #imm" which would naturally use an intrinsic taking an i64 and returning an i32. llvm-svn: 205003
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-272-24/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds back r204781. Original message: Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204934
* llvm-cov: Handle functions with no line numberJustin Bogner2014-03-261-0/+5
| | | | | | | | | Functions may in an instrumented binary but not in the original source when they're inserted by the compiler or the runtime. These functions aren't meaningful to the user, so teach llvm-cov to skip over them instead of crashing. llvm-svn: 204863
* Revert "Prevent alias from pointing to weak aliases."Rafael Espindola2014-03-262-21/+24
| | | | | | | | | This reverts commit r204781. I will follow up to with msan folks to see what is what they were trying to do with aliases to weak aliases. llvm-svn: 204784
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-262-24/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204781
* Disable Visual C++ warning 4722 about aborting a destructor,Yaron Keren2014-03-251-20/+0
| | | | | | it has no value for us. llvm-svn: 204704
* In Release modes, Visual Studio complains that the Operator destructor in ↵Yaron Keren2014-03-241-0/+20
| | | | | | | | | | | | | | | | | | | | | User.cpp never returns, which is true by design. Initially assumed that the reason is llvm_unreachable being dependent on NDEBUG. However, even if llvm_unreachable is replaced by __assume(false), VC still warns in Release modes but not in Debug modes... The real reason turned out to be optimization flags. With /Od in Debug modes the warning is not issued whereas with /O1 it is. I could not find any documentation to this effect, but it is reproducable: Try compiling http://msdn.microsoft.com/en-us/library/khwfyc5d(v=vs.90).aspx with /O1 and then with /Od. llvm-svn: 204659
* remove a bunch of unused private methodsNuno Lopes2014-03-231-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | found with a smarter version of -Wunused-member-function that I'm playwing with. Appologies in advance if I removed someone's WIP code. include/llvm/CodeGen/MachineSSAUpdater.h | 1 include/llvm/IR/DebugInfo.h | 3 lib/CodeGen/MachineSSAUpdater.cpp | 10 -- lib/CodeGen/PostRASchedulerList.cpp | 1 lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | 10 -- lib/IR/DebugInfo.cpp | 12 -- lib/MC/MCAsmStreamer.cpp | 2 lib/Support/YAMLParser.cpp | 39 --------- lib/TableGen/TGParser.cpp | 16 --- lib/TableGen/TGParser.h | 1 lib/Target/AArch64/AArch64TargetTransformInfo.cpp | 9 -- lib/Target/ARM/ARMCodeEmitter.cpp | 12 -- lib/Target/ARM/ARMFastISel.cpp | 84 -------------------- lib/Target/Mips/MipsCodeEmitter.cpp | 11 -- lib/Target/Mips/MipsConstantIslandPass.cpp | 12 -- lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp | 21 ----- lib/Target/NVPTX/NVPTXISelDAGToDAG.h | 2 lib/Target/PowerPC/PPCFastISel.cpp | 1 lib/Transforms/Instrumentation/AddressSanitizer.cpp | 2 lib/Transforms/Instrumentation/BoundsChecking.cpp | 2 lib/Transforms/Instrumentation/MemorySanitizer.cpp | 1 lib/Transforms/Scalar/LoopIdiomRecognize.cpp | 8 - lib/Transforms/Scalar/SCCP.cpp | 1 utils/TableGen/CodeEmitterGen.cpp | 2 24 files changed, 2 insertions(+), 261 deletions(-) llvm-svn: 204560
* Fix comment (PR19188)Hans Wennborg2014-03-191-1/+1
| | | | llvm-svn: 204256
* [C++11] Change DebugInfoFinder to use range-based loopsAlon Mishne2014-03-181-16/+15
| | | | | | Also changes the iterators to return actual DI type over MDNode. llvm-svn: 204130
* Switch the type field in DIVariable and DIGlobalVariable over to DITypeRefs.Adrian Prantl2014-03-182-14/+17
| | | | | | | | | This allows us to catch more opportunities for ODR-based type uniquing during LTO. Paired commit with CFE which updates some testcases to verify the new DIBuilder behavior. llvm-svn: 204106
* Make some assertions on constant expressions static.Benjamin Kramer2014-03-151-2/+2
| | | | llvm-svn: 204011
* Use DiagnosticInfo facility.Diego Novillo2014-03-141-0/+8
| | | | | | | | | | | | | | | | | | Summary: The sample profiler pass emits several error messages. Instead of just aborting the compiler with report_fatal_error, we can emit better messages using DiagnosticInfo. This adds a new sub-class of DiagnosticInfo to handle the sample profiler. Reviewers: chandlerc, qcolombet CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D3086 llvm-svn: 203976
* Remove the linker_private and linker_private_weak linkages.Rafael Espindola2014-03-133-13/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These linkages were introduced some time ago, but it was never very clear what exactly their semantics were or what they should be used for. Some investigation found these uses: * utf-16 strings in clang. * non-unnamed_addr strings produced by the sanitizers. It turns out they were just working around a more fundamental problem. For some sections a MachO linker needs a symbol in order to split the section into atoms, and llvm had no idea that was the case. I fixed that in r201700 and it is now safe to use the private linkage. When the object ends up in a section that requires symbols, llvm will use a 'l' prefix instead of a 'L' prefix and things just work. With that, these linkages were already dead, but there was a potential future user in the objc metadata information. I am still looking at CGObjcMac.cpp, but at this point I am convinced that linker_private and linker_private_weak are not what they need. The objc uses are currently split in * Regular symbols (no '\01' prefix). LLVM already directly provides whatever semantics they need. * Uses of a private name (start with "\01L" or "\01l") and private linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm agrees with clang on L being ok or not for a given section. I have two patches in code review for this. * Uses of private name and weak linkage. The last case is the one that one could think would fit one of these linkages. That is not the case. The semantics are * the linker will merge these symbol by *name*. * the linker will hide them in the final DSO. Given that the merging is done by name, any of the private (or internal) linkages would be a bad match. They allow llvm to rename the symbols, and that is really not what we want. From the llvm point of view, these objects should really be (linkonce|weak)(_odr)?. For now, just keeping the "\01l" prefix is probably the best for these symbols. If we one day want to have a more direct support in llvm, IMHO what we should add is not a linkage, it is just a hidden_symbol attribute. It would be applicable to multiple linkages. For example, on weak it would produce the current behavior we have for objc metadata. On internal, it would be equivalent to private (and we should then remove private). llvm-svn: 203866
* [PM] Stop playing fast and loose with rebinding of references. HoweverChandler Carruth2014-03-131-4/+4
| | | | | | | | convenient it is to imagine a world where this works, that is not C++ as was pointed out in review. The standard even goes to some lengths to preclude any attempt at this, for better or worse. Maybe better. =] llvm-svn: 203775
* Reject alias to undefined symbols in the verifier.Rafael Espindola2014-03-121-0/+1
| | | | | | | | | | | | | | | On ELF and COFF an alias is just another name for a position in the file. There is no way to refer to a position in another file, so an alias to undefined is meaningless. MachO currently doesn't support aliases. The spec has a N_INDR, which when implemented will have a different set of restrictions. Adding support for it shouldn't be harder than any other IR extension. For now, having the IR represent what is actually possible with current tools makes it easier to fix the design of GlobalAlias. llvm-svn: 203705
* Revert r203488 and r203520.Evan Cheng2014-03-121-8/+0
| | | | llvm-svn: 203687
* Avoid repeated calls to CE->getOperand(0). No functionality change.Rafael Espindola2014-03-121-9/+10
| | | | llvm-svn: 203686
* Remove copy ctors that did the same thing as the default one.Benjamin Kramer2014-03-111-10/+0
| | | | | | | The code added nothing but potentially disabled move semantics and made types non-trivially copyable. llvm-svn: 203563
* IR: add a second ordering operand to cmpxhg for failureTim Northover2014-03-115-13/+78
| | | | | | | | | | | | | | | The syntax for "cmpxchg" should now look something like: cmpxchg i32* %addr, i32 42, i32 3 acquire monotonic where the second ordering argument gives the required semantics in the case that no exchange takes place. It should be no stronger than the first ordering constraint and cannot be either "release" or "acq_rel" (since no store will have taken place). rdar://problem/15996804 llvm-svn: 203559
* Module: Don't rename in getOrInsertFunction()Duncan P. N. Exon Smith2014-03-101-10/+0
| | | | | | | | | | | | | | | | | | | | | | | During LTO, user-supplied definitions of C library functions often exist. -instcombine uses Module::getOrInsertFunction() to get a handle on library functions (e.g., @puts, when optimizing @printf). Previously, Module::getOrInsertFunction() would rename any matching functions with local linkage, and create a new declaration. In LTO, this is the opposite of desired behaviour, as it skips by the user-supplied version of the library function and creates a new undefined reference which the linker often cannot resolve. After some discussing with Rafael on the list, it looks like it's undesired behaviour. If a consumer actually *needs* this behaviour, we should add new API with a more explicit name. I added two testcases: one specifically for the -instcombine behaviour and one for the LTO flow. <rdar://problem/16165191> llvm-svn: 203513
* IR: Slightly more verbose error in VerifierJustin Bogner2014-03-101-2/+4
| | | | | | | | | | Extend the error message generated by the Verifier when an intrinsic name does not match the expected mangling to include the expected name. Simplifies debugging. Patch by Philip Reames! llvm-svn: 203490
* For functions with ARM target specific calling convention, when simplify-libcallEvan Cheng2014-03-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | optimize a call to a llvm intrinsic to something that invovles a call to a C library call, make sure it sets the right calling convention on the call. e.g. extern double pow(double, double); double t(double x) { return pow(10, x); } Compiles to something like this for AAPCS-VFP: define arm_aapcs_vfpcc double @t(double %x) #0 { entry: %0 = call double @llvm.pow.f64(double 1.000000e+01, double %x) ret double %0 } declare double @llvm.pow.f64(double, double) #1 Simplify libcall (part of instcombine) will turn the above into: define arm_aapcs_vfpcc double @t(double %x) #0 { entry: %__exp10 = call double @__exp10(double %x) #1 ret double %__exp10 } declare double @__exp10(double) The pre-instcombine code works because calls to LLVM builtins are special. Instruction selection will chose the right calling convention for the call. However, the code after instcombine is wrong. The call to __exp10 will use the C calling convention. I can think of 3 options to fix this. 1. Make "C" calling convention just work since the target should know what CC is being used. This doesn't work because each function can use different CC with the "pcs" attribute. 2. Have Clang add the right CC keyword on the calls to LLVM builtin. This will work but it doesn't match the LLVM IR specification which states these are "Standard C Library Intrinsics". 3. Fix simplify libcall so the resulting calls to the C routines will have the proper CC keyword. e.g. %__exp10 = call arm_aapcs_vfpcc double @__exp10(double %x) #1 This works and is the solution I implemented here. Both solutions #2 and #3 would work. After carefully considering the pros and cons, I decided to implement #3 for the following reasons. 1. It doesn't change the "spec" of the intrinsics. 2. It's a self-contained fix. There are a couple of potential downsides. 1. There could be other places in the optimizer that is broken in the same way that's not addressed by this. 2. There could be other calling conventions that need to be propagated by simplify-libcall that's not handled. But for now, this is the fix that I'm most comfortable with. llvm-svn: 203488
* llvm-c: expose unnamedaddr field of globalsTim Northover2014-03-101-0/+8
| | | | | | Patch by Manuel Jacob. llvm-svn: 203482
* [C++11] Modernize the IR library a bit.Benjamin Kramer2014-03-105-67/+42
| | | | | | No functionality change. llvm-svn: 203465
* [PM] While I'm here, fix a few other clang-format issues. Pulls someChandler Carruth2014-03-101-2/+4
| | | | | | lines under 80-columns, etc. llvm-svn: 203434
* [PM] Switch new pass manager from polymorphic_ptr to unique_ptr now thatChandler Carruth2014-03-091-3/+3
| | | | | | | it is available. Also make the move semantics sufficiently correct to tolerate move-only passes, as the PassManagers *are* move-only passes. llvm-svn: 203391
* IR: Change inalloca's grammar a bitDavid Majnemer2014-03-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The grammar for LLVM IR is not well specified in any document but seems to obey the following rules: - Attributes which have parenthesized arguments are never preceded by commas. This form of attribute is the only one which ever has optional arguments. However, not all of these attributes support optional arguments: 'thread_local' supports an optional argument but 'addrspace' does not. Interestingly, 'addrspace' is documented as being a "qualifier". What constitutes a qualifier? I cannot find a definition. - Some attributes use a space between the keyword and the value. Examples of this form are 'align' and 'section'. These are always preceded by a comma. - Otherwise, the attribute has no argument. These attributes do not have a preceding comma. Sometimes an attribute goes before the instruction, between the instruction and it's type, or after it's type. 'atomicrmw' has 'volatile' between the instruction and the type while 'call' has 'tail' preceding the instruction. With all this in mind, it seems most consistent for 'inalloca' on an 'inalloca' instruction to occur before between the instruction and the type. Unlike the current formulation, there would be no preceding comma. The combination 'alloca inalloca' doesn't look particularly appetizing, perhaps a better spelling of 'inalloca' is down the road. llvm-svn: 203376
* [C++11] Fix break due to MSVC bug.Ahmed Charles2014-03-091-1/+2
| | | | | | | | | | | | | | | MSVC (2012, 2013, 2013 Nov CTP) fail on the following code: int main() { int arr[] = {1, 2}; for (int i : arr) do {} while (0); } The fix is to put {} around the for loop. I've reported this to the MSVC team. llvm-svn: 203371
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-099-36/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* Teach lint about address spacesMatt Arsenault2014-03-061-2/+21
| | | | llvm-svn: 203132
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-064-7/+5
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* [Layering] Move GVMaterializer.h into the IR library where itsChandler Carruth2014-03-062-2/+2
| | | | | | | | | | | | | implementation already lived. After this commit, the only IR-library headers in include/llvm/* are ones related to the legacy pass infrastructure that I'm planning to leave there until the new one is farther along. The only other headers at the top level are linking and initialization aids that aren't really libraries but just headers. llvm-svn: 203069
* [Layering] Move InstVisitor.h into the IR library as it is prettyChandler Carruth2014-03-061-1/+1
| | | | | | obviously coupled to the IR. llvm-svn: 203064
* [Layering] Move DebugInfo.h into the IR library where its implementationChandler Carruth2014-03-066-6/+6
| | | | | | already lives. llvm-svn: 203046
* [Layering] Move DIBuilder.h into the IR library where its implementationChandler Carruth2014-03-061-1/+1
| | | | | | already lives. llvm-svn: 203038
* [Layering] Move AutoUpgrade.h into the IR library where itsChandler Carruth2014-03-051-1/+1
| | | | | | implementation already lives. llvm-svn: 202961
* [Layering] Move DebugLoc.h into the IR library. The implementationChandler Carruth2014-03-051-1/+1
| | | | | | | | | | | already lived there and it is where it belongs -- this is the in-memory debug location representation. This is just cleanup -- Modules can actually cope with this, but that doesn't make it right. After chatting with folks that have out-of-tree stuff, going ahead and moving the rest of the headers seems preferable. llvm-svn: 202960
* [C++11] Replace OwningPtr::take() with OwningPtr::release().Ahmed Charles2014-03-051-2/+2
| | | | llvm-svn: 202957
* [C++11] Add 'override' keyword to IR library.Craig Topper2014-03-058-56/+59
| | | | llvm-svn: 202939
* [C API] Implement LLVM{Get,Set}Alignment for AllocaInst.Peter Zotov2014-03-051-2/+8
| | | | | | Patch by Manuel Jacob. llvm-svn: 202936
* C API: Add functions to get or set a GlobalValue's DLLStorageClassReid Kleckner2014-03-051-0/+10
| | | | | | Patch by Manuel Jacob! llvm-svn: 202928
* [Modules] Move the LeakDetector header into the IR library where theChandler Carruth2014-03-048-8/+8
| | | | | | | | | | | source file had already been moved. Also move the unittest into the IR unittest library. This may seem an odd thing to put in the IR library but we only really use this with instructions and it needs the LLVM context to work, so it is intrinsically tied to the IR library. llvm-svn: 202842
* [Modules] Move the PassNameParser to the IR library as it deals in theChandler Carruth2014-03-042-2/+2
| | | | | | | PassInfo structures of the legacy pass manager. Also give it the Legacy prefix as it is not a particularly widely used header. llvm-svn: 202839
* [Modules] Move the ConstantRange class into the IR library. This isChandler Carruth2014-03-045-3/+738
| | | | | | | | | | a bit surprising, as the class is almost entirely abstracted away from any particular IR, however it encodes the comparsion predicates which mutate ranges as ICmp predicate codes. This is reasonable as they're used for both instructions and constants. Thus, it belongs in the IR library with instructions and constants. llvm-svn: 202838
* [Modules] Move CFG.h to the IR library as it defines graph traits overChandler Carruth2014-03-045-5/+5
| | | | | | IR types. llvm-svn: 202827
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-044-4/+4
| | | | | | | | | | | Move the test for this class into the IR unittests as well. This uncovers that ValueMap too is in the IR library. Ironically, the unittest for ValueMap is useless in the Support library (honestly, so was the ValueHandle test) and so it already lives in the IR unittests. Mmmm, tasty layering. llvm-svn: 202821
* [Modules] Move CallSite into the IR library where it belogs. It isChandler Carruth2014-03-046-6/+6
| | | | | | | abstracting between a CallInst and an InvokeInst, both of which are IR concepts. llvm-svn: 202816
OpenPOWER on IntegriCloud