summaryrefslogtreecommitdiffstats
path: root/llvm/lib/VMCore/AutoUpgrade.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Rename VMCore directory to IR.Chandler Carruth2013-01-021-393/+0
| | | | | | | | | | | | | | | | | | 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
* Attributes RewriteBill Wendling2012-10-151-1/+2
| | | | | | | | | | Convert the internal representation of the Attributes class into a pointer to an opaque object that's uniqued by and stored in the LLVMContext object. The Attributes class then becomes a thin wrapper around this opaque object. Eventually, the internal representation will be expanded to include attributes that represent code generation options, etc. llvm-svn: 165917
* Fix a dangling StringRef bug in the auto upgrader. In one case, we resetChandler Carruth2012-07-201-2/+2
| | | | | | | | | | | CI's name, and then used the StringRef pointing at its old name. I'm fixing it by storing the name in a std::string, and hoisting the renaming logic to happen always. This is nicer anyways as it will allow the upgraded IR to have the same names as the input IR in more cases. Another bug found by AddressSanitizer. Woot. llvm-svn: 160572
* More replacing of target-dependent intrinsics with target-indepdent Joel Jones2012-07-181-1/+11
| | | | | | | | | | | | | | | | | | | | | intrinsics. The second instruction(s) to be handled are the vector versions of count set bits (ctpop). The changes here are to clang so that it generates a target independent vector ctpop when it sees an ARM dependent vector bits set count. The changes in llvm are to match the target independent vector ctpop and in VMCore/AutoUpgrade.cpp to update any existing bc files containing ARM dependent vector pop counts with target-independent ctpops. There are also changes to an existing test case in llvm for ARM vector count instructions and to a test for the bitcode upgrade. <rdar://problem/11892519> There is deliberately no test for the change to clang, as so far as I know, no consensus has been reached regarding how to test neon instructions in clang; q.v. <rdar://problem/8762292> llvm-svn: 160410
* This is one of the first steps at moving to replace target-dependent Joel Jones2012-07-131-0/+25
| | | | | | | | | | | | | | | | | | | | intrinsics with target-indepdent intrinsics. The first instruction(s) to be handled are the vector versions of count leading zeros (ctlz). The changes here are to clang so that it generates a target independent vector ctlz when it sees an ARM dependent vector ctlz. The changes in llvm are to match the target independent vector ctlz and in VMCore/AutoUpgrade.cpp to update any existing bc files containing ARM dependent vector ctlzs with target-independent ctlzs. There are also changes to an existing test case in llvm for ARM vector count instructions and a new test for the bitcode upgrade. <rdar://problem/11831778> There is deliberately no test for the change to clang, as so far as I know, no consensus has been reached regarding how to test neon instructions in clang; q.v. <rdar://problem/8762292> llvm-svn: 160200
* Move llvm/Support/IRBuilder.h -> llvm/IRBuilder.hChandler Carruth2012-06-291-3/+3
| | | | | | | | | | | | | | | | | This was always part of the VMCore library out of necessity -- it deals entirely in the IR. The .cpp file in fact was already part of the VMCore library. This is just a mechanical move. I've tried to go through and re-apply the coding standard's preferred header sort, but at 40-ish files, I may have gotten some wrong. Please let me know if so. I'll be committing the corresponding updates to Clang and Polly, and Duncan has DragonEgg. Thanks to Bill and Eric for giving the green light for this bit of cleanup. llvm-svn: 159421
* Fix intrinsics for XOP frczss/sd instructions. These instructions only take ↵Craig Topper2012-06-131-1/+22
| | | | | | one source register and zero the upper bits of the destination rather than preserving them. llvm-svn: 158396
* Add AutoUpgrade support for the SSE4 ptest intrinsics.Nadav Rotem2012-06-101-6/+59
| | | | | | Patch by Michael Kuperstein. llvm-svn: 158295
* Replace XOP vpcom intrinsics with fewer intrinsics that take the immediate ↵Craig Topper2012-06-091-1/+47
| | | | | | as an argument. llvm-svn: 158278
* Simplify the fma4 renaming code.Craig Topper2012-06-031-71/+3
| | | | llvm-svn: 157902
* Autoupgrade support the rename of x86.fma4 intrinsics to x86.fma from r157898.Craig Topper2012-06-031-0/+74
| | | | llvm-svn: 157899
* revert my previous patches that introduced an additional parameter to the ↵Nuno Lopes2012-05-221-25/+1
| | | | | | | | objectsize intrinsic. After a lot of discussion, we realized it's not the best option for run-time bounds checking llvm-svn: 157255
* change the objectsize intrinsic signature: add a 3rd parameter to denote the ↵Nuno Lopes2012-05-091-1/+25
| | | | | | | | maximum runtime performance penalty that the user is willing to accept. This commit only adds the parameter. Code taking advantage of it will follow. llvm-svn: 156473
* Remove 256-bit AVX non-temporal store intrinsics. Similar was previously ↵Craig Topper2012-05-081-5/+33
| | | | | | done for 128-bit. llvm-svn: 156375
* Remove AVX vpermil intrinsics. I removed their uses from clang headers and ↵Craig Topper2012-04-181-5/+38
| | | | | | builtins a while back. llvm-svn: 154985
* Add auto upgrade support for x86 pcmpgt/pcmpeq intrinics removed in r149367.Craig Topper2012-02-031-3/+40
| | | | llvm-svn: 149678
* Fix unused value warning for value used only in assert.Nick Lewycky2011-12-121-5/+2
| | | | llvm-svn: 146440
* Don't rely in there being one argument before we've actually identifiedChandler Carruth2011-12-121-3/+4
| | | | | | | a function to upgrade. Also, simplify the code a bit at the expense of one line. llvm-svn: 146368
* Switch llvm.cttz and llvm.ctlz to accept a second i1 parameter whichChandler Carruth2011-12-121-6/+33
| | | | | | | | | | | | | | | | | | | | indicates whether the intrinsic has a defined result for a first argument equal to zero. This will eventually allow these intrinsics to accurately model the semantics of GCC's __builtin_ctz and __builtin_clz and the X86 instructions (prior to AVX) which implement them. This patch merely sets the stage by extending the signature of these intrinsics and establishing auto-upgrade logic so that the old spelling still works both in IR and in bitcode. The upgrade logic preserves the existing (inefficient) semantics. This patch should not change any behavior. CodeGen isn't updated because it can use the existing semantics regardless of the flag's value. Note that this will be followed by API updates to Clang and DragonEgg. Reviewed by Nick Lewycky! llvm-svn: 146357
* Eli managed to kill off llvm.membarrier in llvm 3.0 also, this meansChris Lattner2011-11-271-34/+8
| | | | | | that mainline needs no autoupgrade logic for intrinsics yet, woohoo! llvm-svn: 145178
* The llvm.atomic intrinsics *were* removed in LLVM 3.0 (in r141333), remove the Chris Lattner2011-11-271-68/+1
| | | | | | autoupgrade logic for 2.9 and before. llvm-svn: 145176
* remove autoupgrade support for old forms of llvm.prefetch and the oldChris Lattner2011-11-271-101/+1
| | | | | | | trampoline forms. Both of these were correct in LLVM 3.0, and we don't need to support LLVM 2.9 and earlier in mainline. llvm-svn: 145174
* remove autoupgrade support for really old-style debug info intrinsics.Chris Lattner2011-11-271-42/+0
| | | | | | | I think this is the last of autoupgrade that can be removed in 3.1. Can the atomic upgrade stuff also go? llvm-svn: 145169
* remove some old autoupgrade logicChris Lattner2011-11-271-80/+1
| | | | llvm-svn: 145167
* remove autoupgrade support for LLVM 2.9 exception stuff. Mainline supportsChris Lattner2011-11-271-246/+0
| | | | | | LLVM 3.0 and later. llvm-svn: 145165
* Remove the old atomic instrinsics. autoupgrade functionality is included ↵Eli Friedman2011-10-061-0/+91
| | | | | | with this patch. llvm-svn: 141333
* Split the init.trampoline intrinsic, which currently combines GCC'sDuncan Sands2011-09-061-0/+46
| | | | | | | | | | | | | | | | | | | | init.trampoline and adjust.trampoline intrinsics, into two intrinsics like in GCC. While having one combined intrinsic is tempting, it is not natural because typically the trampoline initialization needs to be done in one function, and the result of adjust trampoline is needed in a different (nested) function. To get around this llvm-gcc hacks the nested function lowering code to insert an additional parent variable holding the adjust.trampoline result that can be accessed from the child function. Dragonegg doesn't have the luxury of tweaking GCC code, so it stored the result of adjust.trampoline in the memory GCC set aside for the trampoline itself (this is always available in the child function), and set up some new memory (using an alloca) to hold the trampoline. Unfortunately this breaks Go which allocates trampoline memory on the heap and wants to use it even after the parent has exited (!). Rather than doing even more hacks to get Go working, it seemed best to just use two intrinsics like in GCC. Patch mostly by Sanjoy Das. llvm-svn: 139140
* The insertion point for the loads is right before the llvm.eh.exceptionBill Wendling2011-09-041-1/+1
| | | | | | | | call. The call may be in the same BB as the landingpad instruction. If that's the case, then inserting the loads after the landingpad inst, but before the extractvalues, causes undefined behavior. llvm-svn: 139088
* Don't reload the values that are already there. The llvm.eh.resume uses the sameBill Wendling2011-09-031-7/+4
| | | | | | | values that the resume instruction uses. PR10850 llvm-svn: 139076
* No need to get fancy inserting a PHI node when the values are stored in stackBill Wendling2011-09-021-43/+15
| | | | | | | | slots. This fixes a bug where the number of nodes coming into the PHI node may not equal the number of predecessors. E.g., two or more landingpad instructions may require a PHI before reaching the eh.exception and eh.selector instructions. llvm-svn: 139035
* Perform the upgrading of the old EH to the new EH in a more sane manner.Bill Wendling2011-09-021-34/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | Perform the upgrading in steps. * First, create a map of the invokes to the EH intrinsics. * Next, take that mapping and determine if the invoke's unwind destination has a single predecessor. If not, then create a new empty block to hold the new landingpad instruction. * Create a landingpad instruction into the uwnind destination. Fill it with the values from the old selector. Map the old intrinsic calls to the new landingpad values (there may be multiple landingpad instructions per instrinic call pairs). * Go through the old intrinsic calls, create a PHI node when necessary, and then replace their values with the new values from the landingpad instructions. * Delete all dead instructions. * ??? * Profit! llvm-svn: 138990
* Only delete instructions once.Bill Wendling2011-08-271-5/+6
| | | | llvm-svn: 138700
* Initial check in that will auto-upgrade the old EH scheme to the new EH scheme.Bill Wendling2011-08-251-0/+201
| | | | | | | | | | This upgrade suffers from the problems of the old EH scheme - i.e., that the calls to llvm.eh.exception() and llvm.eh.selector() can wander off and get lost. It makes a valiant effort to reclaim these little lost lambs. This is a first draft, so it hasn't yet been hooked up to the parser. llvm-svn: 138602
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-4/+4
| | | | llvm-svn: 135375
* Convert CallInst and InvokeInst APIs to use ArrayRef.Jay Foad2011-07-151-1/+1
| | | | llvm-svn: 135265
* rework the remaining autoupgrade logic to use a StringRef instead of creating aChris Lattner2011-06-181-49/+34
| | | | | | temporary std::string for every function being checked. llvm-svn: 133355
* rip out a ton of intrinsic modernization logic from AutoUpgrade.cpp, which isChris Lattner2011-06-181-1197/+23
| | | | | | | | | for pre-2.9 bitcode files. We keep x86 unaligned loads, movnt, crc32, and the target indep prefetch change. As usual, updating the testsuite is a PITA. llvm-svn: 133337
* Add one more argument to the prefetch intrinsic to indicate whether it's a dataBruno Cardoso Lopes2011-06-141-0/+47
| | | | | | | or instruction cache access. Update the targets to match it and also teach autoupgrade. llvm-svn: 132976
* CRC32 intrinsics were renamed at revision 132163. This submissionChad Rosier2011-05-271-5/+5
| | | | | | | | fixes aliasing issues with the old and new names as well as adds test cases for the auto-upgrader. Fixes rdar 9472944. llvm-svn: 132207
* Renamed llvm.x86.sse42.crc32 intrinsics; crc64 doesn't exist. Chad Rosier2011-05-261-1/+27
| | | | | | | crc32.[8|16|32] have been renamed to .crc32.32.[8|16|32] and crc64.[8|16|32] have been renamed to .crc32.64.[8|64]. llvm-svn: 132163
* Replace the "movnt" intrinsics with a native store + nontemporal metadata bit.Bill Wendling2011-05-031-0/+32
| | | | | | <rdar://problem/8460511> llvm-svn: 130791
* Reapply r129401 with patch for clang.Bill Wendling2011-04-131-1/+29
| | | | llvm-svn: 129419
* Revert r129401 for now. Clang is using the old way of doing things.Bill Wendling2011-04-121-29/+1
| | | | llvm-svn: 129403
* Remove the unaligned load intrinsics in favor of using native unaligned loads.Bill Wendling2011-04-121-1/+29
| | | | | | | | | Now that we have a first-class way to represent unaligned loads, the unaligned load intrinsics are superfluous. First part of <rdar://problem/8460511>. llvm-svn: 129401
* Remove dead code.Bill Wendling2011-03-301-68/+0
| | | | llvm-svn: 128519
* Add intrinsics @llvm.arm.neon.vmulls and @llvm.arm.neon.vmullu.* back. FrontendsEvan Cheng2011-03-291-1/+0
| | | | | | | | | | | | | | | was lowering them to sext / uxt + mul instructions. Unfortunately the optimization passes may hoist the extensions out of the loop and separate them. When that happens, the long multiplication instructions can be broken into several scalar instructions, causing significant performance issue. Note the vmla and vmls intrinsics are not added back. Frontend will codegen them as intrinsics vmull* + add / sub. Also note the isel optimizations for catching mul + sext / zext are not changed either. First part of rdar://8832507, rdar://9203134 llvm-svn: 128502
* convert ConstantVector::get to use ArrayRef.Chris Lattner2011-02-151-2/+2
| | | | llvm-svn: 125537
* revert my ConstantVector patch, it seems to have made the llvm-gccChris Lattner2011-02-141-2/+2
| | | | | | builders unhappy. llvm-svn: 125504
* Switch ConstantVector::get to use ArrayRef instead of a pointer+sizeChris Lattner2011-02-141-2/+2
| | | | | | idiom. Change various clients to simplify their code. llvm-svn: 125487
* The pshufw instruction came about in MMX2 when SSE was introduced. Don't placeBill Wendling2010-10-041-7/+37
| | | | | | | | | it in with the SSSE3 instructions. Steward! Could you place this chair by the aft sun deck? I'm trying to get away from the Astors. They are such boors! llvm-svn: 115552
OpenPOWER on IntegriCloud