summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGStmtOpenMP.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert commit revision 226786Alexey Bataev2015-01-221-119/+2
| | | | | | Need to add initialization of AtomicInfo::EvaluationKind field llvm-svn: 226787
* [OPENMP] CodeGen for "omp atomic read [seq_cst]" directive.Alexey Bataev2015-01-221-2/+119
| | | | | | | | | | | | | "omp atomic read [seq_cst]" accepts expressions "v=x;". In this patch we perform an atomic load of "x" (using builtin atomic loading instructions or a call to "atomic_load()" for simple lvalues and "kmpc_atomic_start();load <x>;kmpc_atomic_end();" for other lvalues), convert the result of loading to type of "v" (using EmitScalarConversion() for simple types and EmitComplexToScalarConversion() for conversions from complex to scalar) and then store the result in "v".) Differential Revision: http://reviews.llvm.org/D6431 llvm-svn: 226786
* Revert commit r226784.Alexey Bataev2015-01-221-119/+2
| | | | | | Accidentally modified file SemaType.cpp must be restored to its original state. llvm-svn: 226785
* [OPENMP] CodeGen for "omp atomic read [seq_cst]" directive.Alexey Bataev2015-01-221-2/+119
| | | | | | | | | | | | | "omp atomic read [seq_cst]" accepts expressions "v=x;". In this patch we perform an atomic load of "x" (using builtin atomic loading instructions or a call to "atomic_load()" for simple lvalues and "kmpc_atomic_start();load <x>;kmpc_atomic_end();" for other lvalues), convert the result of loading to type of "v" (using EmitScalarConversion() for simple types and EmitComplexToScalarConversion() for conversions from complex to scalar) and then store the result in "v". Differential Revision: http://reviews.llvm.org/D6431 llvm-svn: 226784
* [cleanup] Re-sort *all* #include lines with llvm/utils/sort_includes.pyChandler Carruth2015-01-141-1/+1
| | | | | | | | | | Sorry for the noise, I managed to miss a bunch of recent regressions of include orderings here. This should actually sort all the includes for Clang. Again, no functionality changed, this is just a mechanical cleanup that I try to run periodically to keep the #include lines as regular as possible across the project. llvm-svn: 225979
* 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
* 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
* [OPENMP] Bugfix for processing of global variables in OpenMP regions.Alexey Bataev2014-12-161-3/+36
| | | | | | | | Currently, if global variable is marked as a private OpenMP variable, the compiler crashes in debug version or generates incorrect code in release version. It happens because in the OpenMP region the original global variable is used instead of the generated private copy. It happens because currently globals variables are not captured in the OpenMP region. This patch adds capturing of global variables iff private copy of the global variable must be used in the OpenMP region. Differential Revision: http://reviews.llvm.org/D6259 llvm-svn: 224323
* First patch with codegen of the 'omp for' directive. It implementsAlexander Musman2014-12-151-2/+104
| | | | | | | | | | | | | | | the simplest case, which is used when no chunk_size is specified in the schedule(static) or no 'schedule' clause is specified - the iteration space is divided by the library into chunks that are approximately equal in size, and at most one chunk is distributed to each thread. In this case, we do not need an outer loop in each thread - each thread requests once which iterations range it should handle (using __kmpc_for_static_init runtime call) and then runs the inner loop on this range. Differential Revision: http://reviews.llvm.org/D5865 llvm-svn: 224233
* [OPENMP] Codegen for 'omp barrier' directive.Alexey Bataev2014-12-051-2/+2
| | | | | | | | | Adds generation of call to "i32 kmpc_cancel_barrier(ident_t *, i32)" libcall for explicitly specified barriers (OMP_IDENT_BARRIER_EXPL flag is added to "flags" field of "ident_t" structure). Also this patch replaces all calls to "kmpc_barrier" function by calls of "__kmpc_cancel_barrier" function which provides additional functionality for OpenMP 4.0. Also, library specific enum OpenMPLocationFlags moved to private section of CGOpenMPRuntime class to make it more independent from library implementation. Differential Revision: http://reviews.llvm.org/D6447 llvm-svn: 223444
* [OPENMP] Codegen for 'omp master' directiveAlexey Bataev2014-12-041-2/+7
| | | | | | | | | | | | | | Patch adds 2 library functions to OpenMPRuntime class - int32 kmpc_master(ident_t *, int32 gtid) and void kmpc_end_master(ident_t *, int32 gtid); For 'omp master' directive the next code is generated: if (__kmpc_master(loc, gtid)) { <Associated structured block>; __kmpc_end_master(log, gtid); } Differential Revision: http://reviews.llvm.org/D6473 llvm-svn: 223342
* [OPENMP] Formating and code improvement for codegen of 'omp critical' directive.Alexey Bataev2014-12-011-12/+3
| | | | | | No functional changes, only code improvements. llvm-svn: 223010
* [OPENMP] Codegen for "omp flush" directive.Alexey Bataev2014-11-201-2/+11
| | | | | | | | For each "omp flush" directive a call to "void kmpc_flush(ident_t *, ...)" function is generated. Directive "omp flush" may have an associated list of variables to flush, but currently runtime function ignores them. So the patch generates just "call kmpc_flush(ident_t *<loc>, i32 0)". Differential Revision: http://reviews.llvm.org/D6292 llvm-svn: 222409
* [OPENMP] Codegen for 'private' clause in 'parallel' directive.Alexey Bataev2014-10-211-0/+27
| | | | | | | This patch generates some helper variables which used as a private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by default (with the default constructor, if any). In outlined function references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables and implicit barier is set by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables. Differential Revision: http://reviews.llvm.org/D4752 llvm-svn: 220262
* [OPENMP] Codegen for 'num_threads' clause in 'parallel' directive.Alexey Bataev2014-10-131-6/+20
| | | | | | | This patch generates call to "kmpc_push_num_threads(ident_t *loc, kmp_int32 global_tid, kmp_int32 num_threads);" library function before calling "kmpc_fork_call" each time there is an associated "num_threads" clause in the "omp parallel" directive. Differential Revision: http://reviews.llvm.org/D5145 llvm-svn: 219599
* [OPENMP] Codegen for 'if' clause in 'parallel' directive.Alexey Bataev2014-10-131-2/+60
| | | | | | | | | | | | | | | | | | | | | Adds codegen for 'if' clause. Currently only for 'if' clause used with the 'parallel' directive. If condition evaluates to true, the code executes parallel version of the code by calling __kmpc_fork_call(loc, 1, microtask, captured_struct/*context*/), where loc - debug location, 1 - number of additional parameters after "microtask" argument, microtask - is outlined finction for the code associated with the 'parallel' directive, captured_struct - list of variables captured in this outlined function. If condition evaluates to false, the code executes serial version of the code by executing the following code: global_thread_id.addr = alloca i32 store i32 global_thread_id, global_thread_id.addr zero.addr = alloca i32 store i32 0, zero.addr kmpc_serialized_parallel(loc, global_thread_id); microtask(global_thread_id.addr, zero.addr, captured_struct/*context*/); kmpc_end_serialized_parallel(loc, global_thread_id); Where loc - debug location, global_thread_id - global thread id, returned by __kmpc_global_thread_num() call or passed as a first parameter in microtask() call, global_thread_id.addr - address of the variable, where stored global_thread_id value, zero.addr - implicit bound thread id (should be set to 0 for serial call), microtask() and captured_struct are the same as in parallel call. Also this patch checks if the condition is constant and if it is constant it evaluates its value and then generates either parallel version of the code (if the condition evaluates to true), or the serial version of the code (if the condition evaluates to false). Differential Revision: http://reviews.llvm.org/D4716 llvm-svn: 219597
* Code reformatting and improvement for OpenMP.Alexey Bataev2014-10-101-11/+4
| | | | | | Moved CGOpenMPRegionInfo from CGOpenMPRuntime.h to CGOpenMPRuntime.cpp file and reworked the code for this change. Also added processing of ThreadID variable passed as an argument in outlined functions in parallel and task directives. llvm-svn: 219490
* Code improvements in OpenMP CodeGen.Alexey Bataev2014-10-101-15/+42
| | | | | | This patch makes class OMPPrivateScope a common class for all private variables. Reworked processing of firstprivate variables (now it is based on OMPPrivateScope too). llvm-svn: 219486
* [OPENMP] 'omp teams' directive basic support.Alexey Bataev2014-10-091-0/+4
| | | | | | 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
* [OPENMP] Codegen for 'firstprivate' clause.Alexey Bataev2014-10-081-12/+107
| | | | | | | | This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy. In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables. Differential Revision: http://reviews.llvm.org/D5140 llvm-svn: 219306
* Revert commit r219297.Alexey Bataev2014-10-081-107/+12
| | | | | | Still troubles with OpenMP/parallel_firstprivate_codegen.cpp (now in ARM buildbots). llvm-svn: 219298
* [OPENMP] Codegen for 'firstprivate' clause.Alexey Bataev2014-10-081-12/+107
| | | | | | | | This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy. In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables. Differential Revision: http://reviews.llvm.org/D5140 llvm-svn: 219297
* Revert back r219295.Alexey Bataev2014-10-081-107/+12
| | | | | | To fix issues with test OpenMP/parallel_firstprivate_codegen.cpp llvm-svn: 219296
* [OPENMP] Codegen for 'firstprivate' clause.Alexey Bataev2014-10-081-12/+107
| | | | | | | | This patch generates some helper variables that used as private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by copy using values of the original variables (with the copy constructor, if any). For arrays, initializator is generated for single element and in the codegen procedure this initial value is automatically propagated between all elements of the private copy. In outlined function, references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables an implicit barier is generated by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables. Differential Revision: http://reviews.llvm.org/D5140 llvm-svn: 219295
* Revert "[OPENMP] 'omp teams' directive basic support. Includes parsing and ↵Renato Golin2014-10-081-4/+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/+4
| | | | | | 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] Small refactoring of EmitOMPSimdLoop helper routine.Alexander Musman2014-10-071-14/+14
| | | | | | | | | No functional changes intended. Renamed EmitOMPSimdLoop to EmitOMPInnerLoop, I plan to re-use it to emit inner loop in the future patches for CodeGen of the worksharing loop directives (omp for, omp for simd). llvm-svn: 219195
* [OPENMP] Loop collapsing and codegen for 'omp simd' directive.Alexander Musman2014-10-011-3/+155
| | | | | | | | | | | | | This patch implements collapsing of the loops (in particular, in presense of clause 'collapse'). It calculates number of iterations N and expressions nesessary to calculate the nested loops counters values based on new iteration variable (that goes from 0 to N-1) in Sema. It also adds Codegen for 'omp simd', which uses (and tests) this feature. Differential Revision: http://reviews.llvm.org/D5184 llvm-svn: 218743
* [OPENMP] Codegen of the ‘aligned’ clause for the ‘omp simd’ directive.Alexander Musman2014-09-301-0/+30
| | | | | | Differential Revision: http://reviews.llvm.org/D5499 llvm-svn: 218660
* [OPENMP] Parsing/Sema of directive omp parallel for simdAlexander Musman2014-09-231-0/+5
| | | | llvm-svn: 218299
* [OPENMP] Codegen for 'omp critical' directive.Alexey Bataev2014-09-221-2/+16
| | | | | | | | | | | This patch adds codegen for constructs: #pragma omp critical [name] <body> It generates global variable ".gomp_critical_user_[name].var" of type int32[8]. Then it generates library call "kmpc_critical(loc, gtid, .gomp_critical_user_[name].var)", code for <body> statement and final call "kmpc_end_critical(loc, gtid, .gomp_critical_user_[name].var)". Differential Revision: http://reviews.llvm.org/D5202 llvm-svn: 218239
* [OPENMP] Initial parsing/sema analysis of 'target' directive.Alexey Bataev2014-09-191-0/+4
| | | | llvm-svn: 218110
* Parsing/Sema of directive omp for simdAlexander Musman2014-09-181-0/+4
| | | | llvm-svn: 218029
* [OPENMP] Initial parsing and sema analysis for 'atomic' directive.Alexey Bataev2014-07-221-0/+4
| | | | llvm-svn: 213639
* [OPENMP] Initial parsing and sema analysis for 'ordered' directive.Alexey Bataev2014-07-221-0/+4
| | | | llvm-svn: 213616
* [OPENMP] Initial parsing and sema analysis for 'flush' directive.Alexey Bataev2014-07-211-0/+4
| | | | llvm-svn: 213512
* [OPENMP] Parsing/Sema of the OpenMP directive 'critical'.Alexander Musman2014-07-211-0/+4
| | | | llvm-svn: 213510
* [OPENMP] Initial parsing and sema analysis for 'taskwait' directive.Alexey Bataev2014-07-181-0/+4
| | | | llvm-svn: 213363
* [OPENMP] Initial parsing and sema analysis for 'barrier' directive.Alexey Bataev2014-07-181-0/+4
| | | | llvm-svn: 213360
* [OPENMP] Initial parsing and sema analysis of 'taskyield' directive.Alexey Bataev2014-07-181-0/+4
| | | | llvm-svn: 213355
* [OPENMP] Parsing/Sema analysis of directive 'master'Alexander Musman2014-07-171-0/+4
| | | | llvm-svn: 213237
* [OPENMP] Parsing and sema analysis for 'omp task' directive.Alexey Bataev2014-07-111-0/+4
| | | | llvm-svn: 212804
* [OPENMP] Parsing and sema analysis for 'omp parallel sections' directive.Alexey Bataev2014-07-081-0/+5
| | | | llvm-svn: 212516
* [OPENMP] Added initial support for 'omp parallel for'.Alexey Bataev2014-07-071-0/+5
| | | | llvm-svn: 212453
* Using of variable length arrays in captured statements and OpenMP constructs.Alexey Bataev2014-06-301-2/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D4067 llvm-svn: 212010
OpenPOWER on IntegriCloud