aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/SjLjEHPrepare.cpp
AgeCommit message (Collapse)AuthorFilesLines
2014-11-19Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie1-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
2014-11-13Use nullptr instead of NULL for variadic sentinelsReid Kleckner1-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
2014-08-24Use range based for loops to avoid needing to re-mention SmallPtrSet size.Craig Topper1-4/+2
llvm-svn: 216351
2014-08-21Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper1-1/+1
needing to mention the size. llvm-svn: 216158
2014-08-18Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper1-1/+1
avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
2014-08-17Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper1-1/+1
needing to mention the size. llvm-svn: 215868
2014-08-04Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher1-1/+2
information and update all callers. No functional change. llvm-svn: 214781
2014-07-21Revert "[C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) ↵Duncan P. N. Exon Smith1-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
2014-07-20[C++11] Add predecessors(BasicBlock *) / successors(BasicBlock *) iterator ↵Manuel Jacob1-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
2014-07-14Unify the lowering of arguments during SjLj prepare.Bill Wendling1-28/+10
The 'select true, %arg, undef' instruction can be used for both aggregate and non-aggregate arguments. llvm-svn: 212967
2014-07-14Support lowering of empty aggregates.Bill Wendling1-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
2014-04-22[Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth1-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
2014-04-14[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper1-4/+4
instead of comparing to nullptr. llvm-svn: 206142
2014-03-09[C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth1-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
2014-03-07[C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper1-4/+4
class. llvm-svn: 203220
2014-03-02[C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer1-1/+1
Remove the old functions. llvm-svn: 202636
2014-01-21CodeGen: Stop treating vectors as aggregatesDuncan P. N. Exon Smith1-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
2013-09-23Reformat code with clang-format.Bill Wendling1-107/+108
llvm-svn: 191226
2013-06-19Access the TargetLoweringInfo from the TargetMachine object instead of ↵Bill Wendling1-5/+6
caching it. The TLI may change between functions. No functionality change. llvm-svn: 184349
2013-05-14Add bitcast to store of personality function.Kai Nacke1-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
2013-03-08Revert r176154 in favor of a better approach.Bill Wendling1-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
2013-01-11Split TargetLowering into a CodeGen and a SelectionDAG part.Benjamin Kramer1-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
2013-01-02Move all of the header files which are involved in modelling the LLVM IRChandler Carruth1-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
2012-12-03Use the new script to sort the includes of every file under lib.Chandler Carruth1-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
2012-10-08Move TargetData to DataLayout.Micah Villmow1-2/+2
llvm-svn: 165402
2012-09-03IRBuilderify the SjlLjEHPrepare pass.Benjamin Kramer1-57/+25
No functionality change. llvm-svn: 163115
2012-06-29Move llvm/Support/IRBuilder.h -> llvm/IRBuilder.hChandler Carruth1-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
2012-03-16Revert r152705, which reapplied r152486 as this appears to be causing failuresChad Rosier1-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
2012-03-14Reapply r152486 with a fix for the nightly testers.Bill Wendling1-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
2012-03-13s/SjLjEHPass/SjLjEHPrepare/Bill Wendling1-17/+17
No functionality change. llvm-svn: 152658
2012-03-12Revert due to nightly test failures.Bill Wendling1-82/+32
--- Reverse-merging r152486 into '.': U lib/CodeGen/SjLjEHPrepare.cpp llvm-svn: 152571
2012-03-10Implement a more intelligent way of spilling uses across an invoke boundary.Bill Wendling1-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
2012-01-27Place the GEP instructions nearer to the instructions which use them.Bill Wendling1-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
2012-01-07Missing raw_ostream.h breaks MSVC build.Andrew Trick1-0/+1
llvm-svn: 147703
2012-01-06Tracing to help investigate issues with SjLj spill code.Andrew Trick1-0/+2
llvm-svn: 147682
2011-12-14Reapply r146481 with a fix to create the Builder value in the correct place andBill Wendling1-6/+35
with the correct iterator. <rdar://problem/10530851> llvm-svn: 146600
2011-12-14Revert r146481 to review possible miscompilations.Bill Wendling1-33/+6
llvm-svn: 146546
2011-12-13Avoid using the 'insertvalue' instruction here.Bill Wendling1-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
2011-11-16Record landing pads with a SmallSetVector to avoid multiple entries.Bob Wilson1-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
2011-11-16Update the SP in the SjLj jmpbuf whenever it changes. <rdar://problem/10444602>Bob Wilson1-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
2011-10-24Cleanup. Get rid of the old SjLj EH lowering code. No functionality change.Bill Wendling1-584/+10
llvm-svn: 142800
2011-10-21Make sure that the landing pads themselves have no PHI instructions in them.Bill Wendling1-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
2011-10-17Now Igor, throw the switch...give my creation life!Bill Wendling1-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
2011-10-08Use the code that lowers the arguments and spills any values which are aliveBill Wendling1-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
2011-10-05Fix comment to reflect the new EH stuff.Bill Wendling1-1/+1
llvm-svn: 141218
2011-10-04Generic cleanup.Bill Wendling1-23/+16
llvm-svn: 141050
2011-10-03Don't carry over the dispatchsetup hack from the old system.Bill Wendling1-7/+1
llvm-svn: 141040
2011-10-03Move the grabbing of the jump buffer into the caller function, eliminating ↵Bill Wendling1-31/+33
the need for returning a std::pair. llvm-svn: 141026
2011-09-28Have the SjLjEHPrepare pass do some more heavy lifting.Bill Wendling1-34/+55
Upon further review, most of the EH code should remain written at the IR level. The part which breaks SSA form is the dispatch table, so that part will be moved to the back-end. llvm-svn: 140730
2011-09-28Bitcast the alloca to an i8* to match the intrinsic's signature.Bill Wendling1-1/+4
llvm-svn: 140677
generated by cgit v1.1 at 2025-10-18 08:24:39 +0000