summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGStmt.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Inline asm IR input register constraints don't have early clobberEric Christopher2015-02-061-4/+3
| | | | | | | | modifiers on them. If we have a matching output constraint with an early clobber make sure we don't propagate that to the input constraint. llvm-svn: 228422
* Preserve early clobber flag when using named registers in inline assembly.Daniel Sanders2015-02-041-4/+5
| | | | | | | | | | | | | | | | Summary: Named registers with the constraint "=&r" currently lose the early clobber flag and turn into "=r" when converted to LLVM-IR. This patch correctly passes it on. Reviewers: atanasyan Reviewed By: atanasyan Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7346 llvm-svn: 228143
* Address review feedback for r228003.Adrian Prantl2015-02-031-2/+2
| | | | | | | - use named constructors - get rid of MarkAsPrologue llvm-svn: 228021
* Merge ArtificialLocation into ApplyDebugLocation and make a clearAdrian Prantl2015-02-031-4/+4
| | | | | | | | | | | | | | | | distinction between the different use-cases. With the previous default behavior we would occasionally emit empty debug locations in situations where they actually were strictly required (= on invoke insns). We now have a choice between defaulting to an empty location or an artificial location. Specifically, this fixes a bug caused by a missing debug location when emitting C++ EH cleanup blocks from within an artificial function, such as an ObjC destroy helper function. rdar://problem/19670595 llvm-svn: 228003
* Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info ↵David Blaikie2015-01-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | location handling (and follow-up commits). Several pieces of code were relying on implicit debug location setting which usually lead to incorrect line information anyway. So I've fixed those (in r225955 and r225845) separately which should pave the way for this commit to be cleanly reapplied. The reason these implicit dependencies resulted in crashes with this patch is that the debug location would no longer implicitly leak from one place to another, but be set back to invalid. Once a call with no/invalid location was emitted, if that call was ever inlined it could produce invalid debugloc chains and assert during LLVM's codegen. There may be further cases of such bugs in this patch - they're hard to flush out with regression testing, so I'll keep an eye out for reports and investigate/fix them ASAP if they come up. Original commit message: Reapply "DebugInfo: Generalize debug info location handling" Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Recommitted in r224941 and reverted in r224970 after it caused a crash when building compiler-rt. Looks to be due to this change zeroing out the debug location when emitting default arguments (which were meant to inherit their outer expression's location) thus creating call instructions without locations - these create problems for inlining and must not be created. That is fixed and tested in this version of the change. Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 225956
* CodeGen: Simplify consecutive '%' modifiersDavid Majnemer2015-01-111-2/+3
| | | | | | LLVM the consecutive '%' modifiers are redundant, skip them. llvm-svn: 225602
* CodeGen: Simplify consecutive '&' modifiersDavid Majnemer2015-01-111-0/+5
| | | | | | LLVM the consecutive '&' modifiers are redundant, skip them. llvm-svn: 225601
* Revert "DebugInfo: Generalize debug info location handling" and related commitsDavid Blaikie2015-01-091-2/+2
| | | | | | | | | | | | This reverts commit r225000, r225021, r225083, r225086, r225090. The root change (r225000) still has several issues where it's caused calls to be emitted without debug locations. This causes assertion failures if/when those calls are inlined. I'll work up some test cases and fixes before recommitting this. llvm-svn: 225555
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Recommitted in r224941 and reverted in r224970 after it caused a crash when building compiler-rt. Looks to be due to this change zeroing out the debug location when emitting default arguments (which were meant to inherit their outer expression's location) thus creating call instructions without locations - these create problems for inlining and must not be created. That is fixed and tested in this version of the change. Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 225000
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-291-2/+2
| | | | | | | | | Asserting when building compiler-rt when using a GCC host compiler. Reverting while I investigate. This reverts commit r224941. llvm-svn: 224970
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 224941
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-171-2/+2
| | | | | | | | | Fails an ASan bootstrap - I'll try to reproduce locally & sort that out before recommitting. This reverts commit r224385. llvm-svn: 224441
* DebugInfo: Generalize debug info location handlingDavid Blaikie2014-12-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 224385
* IR: Update clang for Metadata/Value split in r223802Duncan P. N. Exon Smith2014-12-091-10/+15
| | | | | | Match LLVM API changes from r223802. llvm-svn: 223803
* InstrProf: Use LLVM's -instrprof pass for profilingJustin Bogner2014-12-081-2/+0
| | | | | | | | The logic for lowering profiling counters has been moved to an LLVM pass. Emit the intrinsics rather than duplicating the whole pass in clang. llvm-svn: 223683
* Improved capturing variable-length array types in CapturedStmt.Alexey Bataev2014-10-291-28/+24
| | | | | | | | An updated implemnentation of VLA types capturing based on previously committed solution for Lambdas. This version captures the whole VLA type instead of particular variables which are part of VLA size expression and allows to use previusly calculated size of VLA type in captured regions. Required for OpenMP. Differential Revision: http://reviews.llvm.org/D5099 llvm-svn: 220850
* Allow constant expressions in pragma loop hints.Tyler Nowicki2014-10-121-2/+9
| | | | | | | | Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
* [OPENMP] 'omp teams' directive basic support.Alexey Bataev2014-10-091-0/+3
| | | | | | Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive. llvm-svn: 219385
* Revert "[OPENMP] 'omp teams' directive basic support. Includes parsing and ↵Renato Golin2014-10-081-3/+0
| | | | | | | | | semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive." This reverts commit r219197 because it broke ARM self-hosting buildbots with segmentation fault errors in many tests. llvm-svn: 219289
* [OPENMP] 'omp teams' directive basic support.Alexey Bataev2014-10-071-0/+3
| | | | | | Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive. llvm-svn: 219197
* [OPENMP] Parsing/Sema of directive omp parallel for simdAlexander Musman2014-09-231-0/+3
| | | | llvm-svn: 218299
* [OPENMP] Initial parsing/sema analysis of 'target' directive.Alexey Bataev2014-09-191-0/+3
| | | | llvm-svn: 218110
* Parsing/Sema of directive omp for simdAlexander Musman2014-09-181-0/+3
| | | | llvm-svn: 218029
* MS inline asm: Allow __asm blocks to set a return valueReid Kleckner2014-09-041-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | If control falls off the end of a function after an __asm block, MSVC assumes that the inline assembly filled the EAX and possibly EDX registers with an appropriate return value. This functionality is used in inline functions returning 64-bit integers in system headers, so we need some amount of compatibility. This is implemented in Clang by adding extra output constraints to every inline asm block, and storing the resulting output registers into the return value slot. If we see an asm block somewhere in the function body, we emit a normal epilogue instead of marking the end of the function with a return type unreachable. Normal returns in functions not using this functionality will overwrite the return value slot, and in most cases LLVM should be able to eliminate the dead stores. Fixes PR17201. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D5177 llvm-svn: 217187
* 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: 216528
* Fix some cases were ArrayRefs were being passed by reference.Craig Topper2014-08-271-5/+5
| | | | llvm-svn: 216527
* DebugInfo: for loop backedge should be attributed to the start of the for ↵David Blaikie2014-08-221-0/+2
| | | | | | | | | | | | | | | | statement. Similar to r215768 (which fixed the same case for while loops). To quote r215768's commit message: "A little test case simplification - this could be simplified further, though there are certainly interesting connections to the if/else construct so I'm hesitant to remove that entirely though it does appear somewhat unrelated. (similar fix to r215766, related to PR19864)" llvm-svn: 216297
* DebugInfo: Provide scopes for C++11 range-for loop variables similar to ↵David Blaikie2014-08-221-9/+2
| | | | | | r216288 (which was for plain-for loop condition variables). llvm-svn: 216291
* DebugInfo: Scope for condition variables more narrowly than the loop variable.David Blaikie2014-08-221-9/+2
| | | | | | | | for loops introduce two scopes - one for the outer loop variable and its initialization, and another for the body of the loop, including any variable declared inside the loop condition. llvm-svn: 216288
* DebugInfo: While loop backedge should be attribute to the start of the while ↵David Blaikie2014-08-151-0/+1
| | | | | | | | | | | | | statement. A little test case simplification - this could be simplified further, though there are certainly interesting connections to the if/else construct so I'm hesitant to remove that entirely though it does appear somewhat unrelated. (similar fix to r215766, related to PR19864) llvm-svn: 215768
* DebugInfo: Fix PR19864 better - attribute the jump at the end of a range-for ↵David Blaikie2014-08-151-0/+1
| | | | | | | | | | | | | | | loop, to the start of the loop. This avoids debuggers stepping to strange places (like the last statement in the loop body, or the first statement in the if). This is not the whole answer, though - similar bugs no doubt exist in other loops (patches to follow) and attributing exception handling code to the correct line is also tricky (based on the previous fix to PR19864, exception handling is still erroneously attributed to the 'if' line). llvm-svn: 215766
* Add a state variable to the loop hint attribute.Tyler Nowicki2014-07-311-3/+4
| | | | | | | | | | This patch is necessary to support constant expressions which replaces the integer value in the loop hint attribute with an expression. The integer value was also storing the pragma’s state for options like vectorize(enable/disable) and the pragma unroll and nounroll directive. The state variable is introduced to hold the state of those options/pragmas. This moves the validation of the state (keywords) from SemaStmtAttr handler to the loop hint annotation token handler. Resubmit with changes to try to fix the build-bot issue. Reviewed by Aaron Ballman llvm-svn: 214432
* Revert r214333, "Add a state variable to the loop hint attribute."NAKAMURA Takumi2014-07-311-4/+3
| | | | | | It brought undefined behavior. llvm-svn: 214376
* Add a state variable to the loop hint attribute.Tyler Nowicki2014-07-301-3/+4
| | | | | | | | This patch is necessary to support constant expressions which replaces the integer value in the loop hint attribute with an expression. The integer value was also storing the pragma’s state for options like vectorize(enable/disable) and the pragma unroll and nounroll directive. The state variable is introduced to hold the state of those options/pragmas. This moves the validation of the state (keywords) from SemaStmtAttr handler to the loop hint annotation token handler. Reviewed by Aaron Ballman llvm-svn: 214333
* Add a location to MS inline asm blobsReid Kleckner2014-07-281-2/+7
| | | | | | | | | | | | | | | | | | | | | | This isn't nearly as elaborate as the GCC inline asm which emits an array of source locations, but it's very, very hard to trigger backend diagnostics in MS inline asm because we parse it up front with good source information, unlike GCC inline asm. Currently I can trigger a "inline assembly requires more registers than available" diagnostic with this code: void foo(); void bar() { __asm pusha __asm call foo __asm popa } However, if I committed that as a test case, I would have to remove it once I fix PR20052. llvm-svn: 214141
* In unroll pragma syntax and loop hint metadata, change "enable" forms to a ↵Mark Heffernan2014-07-231-8/+7
| | | | | | new form using the string "full". llvm-svn: 213771
* [OPENMP] Initial parsing and sema analysis for 'atomic' directive.Alexey Bataev2014-07-221-0/+3
| | | | llvm-svn: 213639
* [OPENMP] Initial parsing and sema analysis for 'ordered' directive.Alexey Bataev2014-07-221-0/+3
| | | | llvm-svn: 213616
* Rename metadata llvm.loop.vectorize.unroll to llvm.loop.vectorize.interleave.Mark Heffernan2014-07-211-1/+1
| | | | llvm-svn: 213587
* [OPENMP] Initial parsing and sema analysis for 'flush' directive.Alexey Bataev2014-07-211-0/+3
| | | | llvm-svn: 213512
* [OPENMP] Parsing/Sema of the OpenMP directive 'critical'.Alexander Musman2014-07-211-0/+3
| | | | llvm-svn: 213510
* [OPENMP] Initial parsing and sema analysis for 'taskwait' directive.Alexey Bataev2014-07-181-0/+3
| | | | llvm-svn: 213363
* [OPENMP] Initial parsing and sema analysis for 'barrier' directive.Alexey Bataev2014-07-181-0/+3
| | | | llvm-svn: 213360
* [OPENMP] Initial parsing and sema analysis of 'taskyield' directive.Alexey Bataev2014-07-181-0/+3
| | | | llvm-svn: 213355
* [OPENMP] Parsing/Sema analysis of directive 'master'Alexander Musman2014-07-171-0/+3
| | | | llvm-svn: 213237
* [OPENMP] Parsing and sema analysis for 'omp task' directive.Alexey Bataev2014-07-111-0/+3
| | | | llvm-svn: 212804
* Fix the dtor location issues in PR20038 harder.David Blaikie2014-07-101-8/+10
| | | | | | | | | | | | | Originally committed in r211722, this fixed one case of dtor calls being emitted without locations (this causes problems for debug info if the call is then inlined), this caught only some of the cases. Instead of trying to re-enable the location before the cleanup, simply re-enable the location immediately after the unconditional branches in question using a scoped device to ensure the no-location state doesn't leak out arbitrarily. llvm-svn: 212761
* [OPENMP] Parsing and sema analysis for 'omp parallel sections' directive.Alexey Bataev2014-07-081-0/+3
| | | | llvm-svn: 212516
* [OPENMP] Added initial support for 'omp parallel for'.Alexey Bataev2014-07-071-0/+3
| | | | llvm-svn: 212453
* Add an AST node for __leave statements, hook it up.Nico Weber2014-07-071-0/+3
| | | | | | | Codegen is still missing (and I won't work on that), but __leave is now as implemented as __try and friends. llvm-svn: 212425
OpenPOWER on IntegriCloud