summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Function.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* clang-format two code snippets to make the next patch easy to read.Rafael Espindola2014-10-231-4/+4
| | | | llvm-svn: 220484
* Moved out IIT_V64 from common values section.Robert Khasanov2014-10-201-5/+5
| | | | | | Thanks Juergen Ributzka for notice. llvm-svn: 220224
* Fix Intrinsic::getType not working with varargSteven Wu2014-10-201-0/+6
| | | | | | | | VarArg Intrinsic functions are encoded with "void" type as the last argument. Now Intrinsic::getType can correctly return all the intrinsic function type. llvm-svn: 220205
* [AVX512] Added intrinsics for VPCMPEQB and VPCMPEQW.Robert Khasanov2014-09-301-18/+23
| | | | | | Added new operand type for intrinsics (IIT_V64) llvm-svn: 218668
* Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or ↵Craig Topper2014-08-271-1/+1
| | | | | | just letting them be implicitly created. llvm-svn: 216525
* Provide convenient access to the zext/sext attributes of function arguments. ↵Juergen Ributzka2014-08-051-0/+14
| | | | | | NFC. llvm-svn: 214843
* Add a dereferenceable attributeHal Finkel2014-07-181-3/+15
| | | | | | | | | This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
* TableGen: introduce support for MSBuiltinSaleem Abdulrasool2014-07-041-0/+5
| | | | | | | | | | | | | Add MSBuiltin which is similar in vein to GCCBuiltin. This allows for adding intrinsics for Microsoft compatibility to individual instructions. This is needed to permit the creation of ARM specific MSVC extensions. This is not currently in use, and requires an associated change in clang to enable use of the intrinsics defined by this new class. This merely sets the LLVM portion of the infrastructure in place to permit the use of this functionality. A separate set of changes will enable the new intrinsics. llvm-svn: 212350
* Add 'nonnull', a new parameter and return attribute which indicates that the ↵Nick Lewycky2014-05-201-0/+8
| | | | | | pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden! llvm-svn: 209185
* Split GlobalValue into GlobalValue and GlobalObject.Rafael Espindola2014-05-131-2/+2
| | | | | | | | | This allows code to statically accept a Function or a GlobalVariable, but not an alias. This is already a cleanup by itself IMHO, but the main reason for it is that it gives a lot more confidence that the refactoring to fix the design of GlobalAlias is correct. That will be a followup patch. llvm-svn: 208716
* Allow sret on the second parameter as well as the firstReid Kleckner2014-05-091-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | MSVC always places the implicit sret parameter after the implicit this parameter of instance methods. We used to handle this for x86_thiscallcc by allocating the sret parameter on the stack and leaving the this pointer in ecx, but that doesn't handle alternative calling conventions like cdecl, stdcall, fastcall, or the win64 convention. Instead, change the verifier to allow sret on the second parameter. This also requires changing the Mips and X86 backends to return the argument with the sret parameter, instead of assuming that the sret parameter comes first. The Sparc backend also returns sret parameters in a register, but I wasn't able to update it to handle secondary sret parameters. It currently calls report_fatal_error if you feed it an sret in the second parameter. Reviewers: rafael.espindola, majnemer Differential Revision: http://reviews.llvm.org/D3617 llvm-svn: 208453
* Run clang-format in small sections of code to make a patch easier to read.Rafael Espindola2014-05-091-4/+4
| | | | llvm-svn: 208419
* [C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper2014-04-091-6/+6
| | | | | | check instead of comparing to nullptr. llvm-svn: 205831
* Intrinsics: add LLVMHalfElementsVectorType constraintTim Northover2014-03-291-1/+11
| | | | | | | | | | 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-281-12/+21
| | | | | | | | | | | | 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
* Revert r203488 and r203520.Evan Cheng2014-03-121-8/+0
| | | | llvm-svn: 203687
* 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
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Modules] Move the LeakDetector header into the IR library where theChandler Carruth2014-03-041-1/+1
| | | | | | | | | | | 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 CallSite into the IR library where it belogs. It isChandler Carruth2014-03-041-1/+1
| | | | | | | abstracting between a CallInst and an InvokeInst, both of which are IR concepts. llvm-svn: 202816
* [Modules] Move InstIterator out of the Support library, where it had noChandler Carruth2014-03-041-1/+1
| | | | | | | | | | | | | business. This header includes Function and BasicBlock and directly uses the interfaces of both classes. It has to do with the IR, it even has that in the name. =] Put it in the library it belongs to. This is one step toward making LLVM's Support library survive a C++ modules bootstrap. llvm-svn: 202814
* Add an inalloca flag to allocasReid Kleckner2014-01-171-0/+7
| | | | | | | | | | | | | | | | Summary: The only current use of this flag is to mark the alloca as dynamic, even if its in the entry block. The stack adjustment for the alloca can never be folded into the prologue because the call may clear it and it has to be allocated at the top of the stack. Reviewers: majnemer CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2571 llvm-svn: 199525
* Fix llc to not reuse spill slots in functions that invoke setjmp()Mark Seaborn2014-01-141-4/+2
| | | | | | | | | | | | | | | | | | We need to ensure that StackSlotColoring.cpp does not reuse stack spill slots in functions that call "returns_twice" functions such as setjmp(), otherwise this can lead to miscompiled code, because a stack slot would be clobbered when it's still live. This was already handled correctly for functions that call setjmp() (though this wasn't covered by a test), but not for functions that invoke setjmp(). We fix this by changing callsFunctionThatReturnsTwice() to check for invoke instructions. This fixes PR18244. llvm-svn: 199180
* Begin adding docs and IR-level support for the inalloca attributeReid Kleckner2013-12-191-0/+8
| | | | | | | | | | | | | | | | | | | The inalloca attribute is designed to support passing C++ objects by value in the Microsoft C++ ABI. It behaves the same as byval, except that it always implies that the argument is in memory and that the bytes are never copied. This attribute allows the caller to take the address of an outgoing argument's memory and execute arbitrary code to store into it. This patch adds basic IR support, docs, and verification. It does not attempt to implement any lowering or fix any possibly broken transforms. When this patch lands, a complete description of this feature should appear at http://llvm.org/docs/InAlloca.html . Differential Revision: http://llvm-reviews.chandlerc.com/D2173 llvm-svn: 197645
* Enable variable arguments support for intrinsics.Andrew Trick2013-10-311-1/+6
| | | | llvm-svn: 193766
* Initial support for Neon scalar instructions.Jiangning Liu2013-09-241-1/+6
| | | | | | | | | | Patch by Ana Pazos. 1.Added support for v1ix and v1fx types. 2.Added Scalar Pairwise Reduce instructions. 3.Added initial implementation of Scalar Arithmetic instructions. llvm-svn: 191263
* Implement function prefix data as an IR feature.Peter Collingbourne2013-09-161-0/+36
| | | | | | | | | Previous discussion: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html Differential Revision: http://llvm-reviews.chandlerc.com/D1191 llvm-svn: 190773
* Extend 'readonly' and 'readnone' to work on function arguments as well asNick Lewycky2013-07-061-1/+9
| | | | | | | functions. Make the function attributes pass add it to known library functions and when it can deduce it. llvm-svn: 185735
* Add CodeGen support for functions that always return arguments via a new ↵Stephen Lin2013-04-201-0/+7
| | | | | | parameter attribute 'returned', which is taken advantage of in target-independent tail call opportunity detection and in ARM call lowering (when placed on an integral first parameter). llvm-svn: 179925
* minor code style cleanup.Chris Lattner2013-03-201-2/+2
| | | | llvm-svn: 177576
* Cache the result of Function::getIntrinsicID() in a DenseMap attached to the ↵Michael Ilseman2013-03-011-1/+23
| | | | | | | | | | LLVMContext. This reduces the time actually spent doing string to ID conversion and shows a 10% improvement in compile time for a particularly bad case that involves ARM Neon intrinsics (these have many overloads). Patch by Jean-Luc Duprat! llvm-svn: 176365
* Don't assert on empty attributes.Bill Wendling2013-02-211-2/+2
| | | | llvm-svn: 175785
* Add and remove the attribute from the correct slot.Bill Wendling2013-02-201-2/+12
| | | | | | | | | The slot that we're adding/removing the attribute from may not be the same as the attribute coming in. Make sure that they match up before we try to add/remove them. PR15313 llvm-svn: 175684
* Remove the last of uses that use the Attribute object as a collection of ↵Bill Wendling2013-01-231-13/+6
| | | | | | | | | attributes. Collections of attributes are handled via the AttributeSet class now. This finally frees us up to make significant changes to how attributes are structured. llvm-svn: 173228
* Use the AttributeSet when removing multiple attributes. Use Attribute::AttrKindBill Wendling2013-01-231-3/+6
| | | | | | when removing one attribute. This further encapsulates the use of the attributes. llvm-svn: 173214
* Use the AttributeSet when adding multiple attributes and an Attribute::AttrKindBill Wendling2013-01-231-7/+14
| | | | | | when adding a single attribute to the function. llvm-svn: 173210
* More encapsulation work.Bill Wendling2013-01-221-1/+3
| | | | | | | Use the AttributeSet when we're talking about more than one attribute. Add a function that adds a single attribute. No functionality change intended. llvm-svn: 173196
* Support for half intrinsics. Pushes MMX into slower encoding path.Michael Ilseman2013-01-111-17/+22
| | | | llvm-svn: 172159
* Actually update the CMake and Makefile builds correctly, and update theChandler Carruth2013-01-021-6/+6
| | | | | | | | | | code that includes Intrinsics.gen directly. This never showed up in my testing because the old Intrinsics.gen was still kicking around in the make build system and was correct there. =[ Thankfully, some of the bots to clean rebuilds and that caught this. llvm-svn: 171373
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-5/+5
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Rename VMCore directory to IR.Chandler Carruth2013-01-021-0/+665
Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) llvm-svn: 171359
OpenPOWER on IntegriCloud