summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGStmt.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Add assume_safety option for pragma loop vectorize and interleave.Tyler Nowicki2015-06-111-4/+4
| | | | | | | | Specifying #pragma clang loop vectorize(assume_safety) on a loop adds the mem.parallel_loop_access metadata to each load/store operation in the loop. This metadata tells loop access analysis (LAA) to skip memory dependency checking. llvm-svn: 239572
* [CodeGen] Emit Constants for immediate inlineasm arguments.Ahmed Bougacha2015-06-111-0/+10
| | | | | | | | | | | | | | | | | For inline assembly immediate constraints, we currently always use EmitScalarExpr, instead of directly emitting the constant. When the overflow sanitizer is enabled, this generates overflow intrinsics instead of constants. Instead, emit a constant for constraints that either require an immediate (e.g. 'I' on X86), or only accepts constants (immediate or symbolic; i.e., don't accept registers or memory). Fixes PR19763. Differential Revision: http://reviews.llvm.org/D10255 llvm-svn: 239549
* InstrProf: Cede ownership of createProfileWeights to CGFJustin Bogner2015-05-021-8/+8
| | | | | | | | The fact that PGO has a say in how these branch weights are determined isn't interesting to most of CodeGen, so it makes more sense for this API to be accessible via CodeGenFunction rather than CodeGenPGO. llvm-svn: 236380
* InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)Justin Bogner2015-04-231-48/+34
| | | | | | | | | The RegionCounter type does a lot of legwork, but most of it is only meaningful within the implementation of CodeGenPGO. The uses elsewhere in CodeGen generally just want to increment or read counters, so do that directly. llvm-svn: 235664
* Reland r234613 (and follow-ups 234614, 234616, 234618)Reid Kleckner2015-04-141-0/+6
| | | | | | | The frameescape intrinsic cannot be inlined, so I fixed the inliner in r234937. This should address PR23216. llvm-svn: 234942
* Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.Nico Weber2015-04-131-6/+0
| | | | llvm-svn: 234789
* Revert r234786, it contained a bunch of stuff I did not mean to commit.Nico Weber2015-04-131-0/+6
| | | | llvm-svn: 234787
* Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.Nico Weber2015-04-131-6/+0
| | | | llvm-svn: 234786
* [SEH] Re-land r234532, but use internal linkage for all SEH helpersReid Kleckner2015-04-101-0/+6
| | | | | | | | | | Even though these symbols are in a comdat group, the Microsoft linker really wants them to have internal linkage. I'm planning to tweak the mangling in a follow-up change. This is a straight revert with a 1-line fix. llvm-svn: 234613
* Revert r234532 for a bit, it very likely caused http://crbug.com/475768Nico Weber2015-04-101-6/+0
| | | | llvm-svn: 234563
* [SEH] Outline finally blocks using the new variable capture supportReid Kleckner2015-04-091-0/+6
| | | | | | | | | | | | | | | WinEHPrepare was going to have to pattern match the control flow merge and split that the old lowering used, and that wasn't really feasible. Now we can teach WinEHPrepare to pattern match this, which is much simpler: %fp = call i8* @llvm.frameaddress(i32 0) call void @func(iN [01], i8* %fp) This prototype happens to match the prototype used by the Win64 SEH personality function, so this is really simple. llvm-svn: 234532
* [OPENMP] Improved code for generating debug info + generation of all OpenMP ↵Alexey Bataev2015-03-101-0/+2
| | | | | | | | | regions in termination scope Patch adds proper generation of debug info for all OpenMP regions. Also, all OpenMP regions are generated in a termination scope, because standard does not allow to throw exceptions out of structured blocks, associated with the OpenMP regions Differential Revision: http://reviews.llvm.org/D7935 llvm-svn: 231757
* Revert "[OPENMP] Improved code for generating debug info + generation of all ↵Rafael Espindola2015-03-101-2/+0
| | | | | | | | | | | | | OpenMP regions in termination scope Patch adds proper generation of debug info for all OpenMP regions. Also, all OpenMP regions are generated in a termination scope, because standard does not allow to throw exceptions out of structured blocks, associated with the OpenMP regions Differential Revision: http://reviews.llvm.org/D7935" This reverts commit r231752. It was failing to link with cmake: lib64/libclangCodeGen.a(CGOpenMPRuntime.cpp.o):/home/espindola/llvm/llvm/tools/clang/lib/CodeGen/CGOpenMPRuntime.cpp:function clang::CodeGen::InlinedOpenMPRegionRAII::~InlinedOpenMPRegionRAII(): error: undefined reference to 'clang::CodeGen::EHScopeStack::popTerminate()' clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation) llvm-svn: 231754
* [OPENMP] Improved code for generating debug info + generation of all OpenMP ↵Alexey Bataev2015-03-101-0/+2
| | | | | | | | | regions in termination scope Patch adds proper generation of debug info for all OpenMP regions. Also, all OpenMP regions are generated in a termination scope, because standard does not allow to throw exceptions out of structured blocks, associated with the OpenMP regions Differential Revision: http://reviews.llvm.org/D7935 llvm-svn: 231752
* [ms] Implement codegen for __leave.Nico Weber2015-02-121-3/+2
| | | | | | Reviewed at http://reviews.llvm.org/D7575 llvm-svn: 228977
* 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
OpenPOWER on IntegriCloud