summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SjLjEHPrepare.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-1/+1
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* Simplify IRBuilder::CreateCall* by using ArrayRef+initializer_list/braced ↵David Blaikie2015-05-181-2/+2
| | | | | | init only llvm-svn: 237624
* [opaque pointer type] More GEP API migrationsDavid Blaikie2015-04-041-17/+26
| | | | llvm-svn: 234108
* Opaque Pointer Types: GEP API migrations to specify the gep type explicitlyDavid Blaikie2015-03-241-1/+2
| | | | | | | | | | | | | | The changes to InstCombine do seem a bit silly - it doesn't make anything obviously better to have the caller access the pointers element type (the thing I'm trying to remove) than the GEP itself, but it's a helpful migration step. This will allow me to more obviously lock down GEP (& Load, etc) API usage, then fix all the code that accesses pointer element types except the places that need to be removed (most of the InstCombines) anyway - at which point I'll need to just remove all that code because it won't be meaningful anymore (there will be no pointer types, so no bitcasts to combine) llvm-svn: 233126
* Replace some uses of getSubtargetImpl with the cached versionEric Christopher2015-01-271-1/+1
| | | | | | | off of the MachineFunction or with the version that takes a Function reference as an argument. llvm-svn: 227185
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-1/+1
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* Use nullptr instead of NULL for variadic sentinelsReid Kleckner2014-11-131-1/+1
| | | | | | | | | | Windows defines NULL to 0, which when used as an argument to a variadic function, is not a null pointer constant. As a result, Clang's -Wsentinel fires on this code. Using '0' would be wrong on most 64-bit platforms, but both MSVC and Clang make it work on Windows. Sidestep the issue with nullptr. llvm-svn: 221940
* Use range based for loops to avoid needing to re-mention SmallPtrSet size.Craig Topper2014-08-241-4/+2
| | | | llvm-svn: 216351
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-1/+1
| | | | | | needing to mention the size. llvm-svn: 216158
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-1/+1
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-1/+1
| | | | | | needing to mention the size. llvm-svn: 215868
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-1/+2
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Revert "[C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) ↵Duncan P. N. Exon Smith2014-07-211-2/+2
| | | | | | | | | iterator ranges." This reverts commit r213474 (and r213475), which causes a miscompile on a stage2 LTO build. I'll reply on the list in a moment. llvm-svn: 213562
* [C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) iterator ↵Manuel Jacob2014-07-201-2/+2
| | | | | | | | | | | | | | | | | | ranges. Summary: This patch introduces two new iterator ranges and updates existing code to use it. No functional change intended. Test Plan: All tests (make check-all) still pass. Reviewers: dblaikie Reviewed By: dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D4481 llvm-svn: 213474
* Unify the lowering of arguments during SjLj prepare.Bill Wendling2014-07-141-28/+10
| | | | | | | The 'select true, %arg, undef' instruction can be used for both aggregate and non-aggregate arguments. llvm-svn: 212967
* Support lowering of empty aggregates.Bill Wendling2014-07-141-11/+11
| | | | | | | | | | | | | This crash was pretty common while compiling Rust for iOS (armv7). Reason - SjLj preparation step was lowering aggregate arguments as ExtractValue + InsertValue. ExtractValue has assertion which checks that there is some data in value, which is not true in case of empty (no fields) structures. Rust uses them quite extensively so this patch uses a 'select true, %val, undef' instruction to lower the argument. Patch by Valerii Hiora. llvm-svn: 212922
* [Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | | | define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. llvm-svn: 206837
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-141-4/+4
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-071-4/+4
| | | | | | class. llvm-svn: 203220
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-1/+1
| | | | | | Remove the old functions. llvm-svn: 202636
* CodeGen: Stop treating vectors as aggregatesDuncan P. N. Exon Smith2014-01-211-1/+1
| | | | | | | | | Fix a crash in SjLjEHPrepare::lowerIncomingArguments caused by treating VectorType like an aggregate. It's first-class! <rdar://problem/15854596> llvm-svn: 199768
* Reformat code with clang-format.Bill Wendling2013-09-231-107/+108
| | | | llvm-svn: 191226
* Access the TargetLoweringInfo from the TargetMachine object instead of ↵Bill Wendling2013-06-191-5/+6
| | | | | | caching it. The TLI may change between functions. No functionality change. llvm-svn: 184349
* Add bitcast to store of personality function.Kai Nacke2013-05-141-1/+3
| | | | | | | | | | The personality function is user defined and may have an arbitrary result type. The code assumes always i8*. This results in an assertion failure if a different type is used. A bitcast to i8* is added to prevent this failure. Reviewed by: Renato Golin, Bob Wilson llvm-svn: 181802
* Revert r176154 in favor of a better approach.Bill Wendling2013-03-081-2/+11
| | | | | | | | | | | | | | | | | | | Code generation makes some basic assumptions about the IR it's been given. In particular, if there is only one 'invoke' in the function, then that invoke won't be going away. However, with the advent of the `llvm.donothing' intrinsic, those invokes may go away. If all of them go away, the landing pad no longer has any users. This confuses the back-end, which asserts. This happens with SjLj exceptions, because that's the model that modifies the IR based on there being invokes, etc. in the function. Remove any invokes of `llvm.donothing' during SjLj EH preparation. This will give us a CFG that the back-end won't be confused about. If all of the invokes in a function are removed, then the SjLj EH prepare pass won't insert the bogus code the relies upon the invokes being there. <rdar://problem/13228754&13316637> llvm-svn: 176677
* Split TargetLowering into a CodeGen and a SelectionDAG part.Benjamin Kramer2013-01-111-3/+3
| | | | | | | | | This fixes some of the cycles between libCodeGen and libSelectionDAG. It's still a complete mess but as long as the edges consist of virtual call it doesn't cause breakage. BasicTTI did static calls and thus broke some build configurations. llvm-svn: 172246
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-8/+8
| | | | | | | | | | | | | | | | | | | | | 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
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-7/+7
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Move TargetData to DataLayout.Micah Villmow2012-10-081-2/+2
| | | | llvm-svn: 165402
* IRBuilderify the SjlLjEHPrepare pass.Benjamin Kramer2012-09-031-57/+25
| | | | | | No functionality change. llvm-svn: 163115
* Move llvm/Support/IRBuilder.h -> llvm/IRBuilder.hChandler Carruth2012-06-291-10/+10
| | | | | | | | | | | | | | | | | 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
* Revert r152705, which reapplied r152486 as this appears to be causing failuresChad Rosier2012-03-161-128/+34
| | | | | | | | | | | on our internal nightly testers. So, basically revert r152486 again. Abbreviated original commit message: Implement a more intelligent way of spilling uses across an invoke boundary. It looks as if Chander's inlining work, r152737, exposed an issue. llvm-svn: 152887
* Reapply r152486 with a fix for the nightly testers.Bill Wendling2012-03-141-34/+128
| | | | | | | | | There were cases where a value could be used and it's both crossing an invoke and NOT crossing an invoke. This could happen in the landing pads. In that case, we will demote the value to the stack like we did before. <rdar://problem/10609139> llvm-svn: 152705
* s/SjLjEHPass/SjLjEHPrepare/Bill Wendling2012-03-131-17/+17
| | | | | | No functionality change. llvm-svn: 152658
* Revert due to nightly test failures.Bill Wendling2012-03-121-82/+32
| | | | | | | --- Reverse-merging r152486 into '.': U lib/CodeGen/SjLjEHPrepare.cpp llvm-svn: 152571
* Implement a more intelligent way of spilling uses across an invoke boundary.Bill Wendling2012-03-101-32/+82
| | | | | | | | | | | | | The old way of determine when and where to spill a value that was used inside of a landing pad resulted in spilling that value everywhere and not just at the invoke edge. This algorithm determines which values are used within a landing pad. It then spills those values before the invoke and reloads them before the uses. This should prevent excessive spilling in many cases, e.g. inside of loops. <rdar://problem/10609139> llvm-svn: 152486
* Place the GEP instructions nearer to the instructions which use them.Bill Wendling2012-01-271-37/+36
| | | | | | | | | | | GEP instructions are there for the compiler and shouldn't really output much code (if any at all). When a GEP is stored in the entry block, Fast ISel (for one) will not know that it could fold it into further uses. For instance, inside of the EH handling code. This results in a lot of unnecessary spills and loads which bloat code and slows down pretty much everything. <rdar://problem/10694814> llvm-svn: 149114
* Missing raw_ostream.h breaks MSVC build.Andrew Trick2012-01-071-0/+1
| | | | llvm-svn: 147703
* Tracing to help investigate issues with SjLj spill code.Andrew Trick2012-01-061-0/+2
| | | | llvm-svn: 147682
* Reapply r146481 with a fix to create the Builder value in the correct place andBill Wendling2011-12-141-6/+35
| | | | | | | with the correct iterator. <rdar://problem/10530851> llvm-svn: 146600
* Revert r146481 to review possible miscompilations.Bill Wendling2011-12-141-33/+6
| | | | llvm-svn: 146546
* Avoid using the 'insertvalue' instruction here.Bill Wendling2011-12-131-6/+33
| | | | | | | | | Fast ISel isn't able to handle 'insertvalue' and it causes a large slowdown during -O0 compilation. We don't necessarily need to generate an aggregate of the values here if they're just going to be extracted directly afterwards. <rdar://problem/10530851> llvm-svn: 146481
* Record landing pads with a SmallSetVector to avoid multiple entries.Bob Wilson2011-11-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There may be many invokes that share one landing pad, and the previous code would record the landing pad once for each invoke. Besides the wasted effort, a pair of volatile loads gets inserted every time the landing pad is processed. The rest of the code can get optimized away when a landing pad is processed repeatedly, but the volatile loads remain, resulting in code like: LBB35_18: Ltmp483: ldr r2, [r7, #-72] ldr r2, [r7, #-68] ldr r2, [r7, #-72] ldr r2, [r7, #-68] ldr r2, [r7, #-72] ldr r2, [r7, #-68] ldr r2, [r7, #-72] ldr r2, [r7, #-68] ldr r2, [r7, #-72] ldr r2, [r7, #-68] ldr r2, [r7, #-72] ldr r2, [r7, #-68] ldr r2, [r7, #-72] ldr r2, [r7, #-68] ldr r2, [r7, #-72] ldr r2, [r7, #-68] ldr r4, [r7, #-72] ldr r2, [r7, #-68] llvm-svn: 144787
* Update the SP in the SjLj jmpbuf whenever it changes. <rdar://problem/10444602>Bob Wilson2011-11-161-3/+21
| | | | | | | This same basic code was in the older version of the SjLj exception handling, but it was removed in the recent revisions to that code. It needs to be there. llvm-svn: 144782
* Cleanup. Get rid of the old SjLj EH lowering code. No functionality change.Bill Wendling2011-10-241-584/+10
| | | | llvm-svn: 142800
* Make sure that the landing pads themselves have no PHI instructions in them.Bill Wendling2011-10-211-0/+21
| | | | | | | | The assumption in the back-end is that PHIs are not allowed at the start of the landing pad block for SjLj exceptions. <rdar://problem/10313708> llvm-svn: 142689
* Now Igor, throw the switch...give my creation life!Bill Wendling2011-10-171-0/+1
| | | | | | | | | | | | | | | | | Use the custom inserter for the ARM setjmp intrinsics. Instead of creating the SjLj dispatch table in IR, where it frequently violates serveral assumptions -- in particular assumptions made by the landingpad instruction about what can branch to a landing pad and what cannot. Performing this in the back-end allows us to violate these assumptions without the IR getting angry at us. It also allows us to perform a small optimization. We can shove the address of the dispatch's basic block into the function context and not have to add code around the setjmp to check for the return value and jump to the dispatch. Neat, huh? <rdar://problem/10116753> llvm-svn: 142294
* Use the code that lowers the arguments and spills any values which are aliveBill Wendling2011-10-081-2/+125
| | | | | | | | across unwind edges. This is for the back-end which expects such things. The code is from the original SjLj EH pass. llvm-svn: 141463
* Fix comment to reflect the new EH stuff.Bill Wendling2011-10-051-1/+1
| | | | llvm-svn: 141218
OpenPOWER on IntegriCloud