summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGStmtOpenMP.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [OPENMP] Codegen for 'firstprivate' clause in 'for' directive.Alexey Bataev2015-04-151-57/+79
| | | | | | | | Adds proper codegen for 'firstprivate' clause in for directive. Initially codegen for 'firstprivate' clause was implemented for 'parallel' directive only. Also this patch emits sync point only after initialization of firstprivate variables, not all private variables. This sync point is not required for privates, lastprivates etc., only for initialization of firstprivate variables. Differential Revision: http://reviews.llvm.org/D8660 llvm-svn: 234978
* [OPENMP] Fixed codegen for arrays in 'copyprivate' clause.Alexey Bataev2015-04-141-73/+113
| | | | | | | Fixed a bug with codegen of variables with array types specified in 'copyprivate' clause of 'single' directive. Differential Revision: http://reviews.llvm.org/D8914 llvm-svn: 234856
* [OPENMP] Initial codegen for 'parallel sections' directive.Alexey Bataev2015-04-141-22/+32
| | | | | | | | | | | | | | | Emits code for outlined 'parallel' directive with the implicitly inlined 'sections' directive: ... call __kmpc_fork_call(..., outlined_function, ...); ... define internal void outlined_function(...) { <code for implicit sections directive>; } Differential Revision: http://reviews.llvm.org/D8997 llvm-svn: 234849
* [OPENMP] Initial codegen for 'parallel for' directive.Alexey Bataev2015-04-131-3/+14
| | | | | | | Allows generation of combined 'parallel for' directive that represents 'parallel' region with internal implicit 'for' worksharing region. Differential Revision: http://reviews.llvm.org/D8631 llvm-svn: 234722
* [OPENMP] Codegen for 'reduction' clause in 'parallel' directive.Alexey Bataev2015-04-101-96/+185
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Emit a code for reduction clause. Next code should be emitted for reductions: static kmp_critical_name lock = { 0 }; void reduce_func(void *lhs[<n>], void *rhs[<n>]) { ... *(Type<i> *)lhs[i] = RedOp<i>(*(Type<i> *)lhs[i], *(Type<i> *)rhs[i]); ... } ... void *RedList[<n>] = {&<RHSExprs>[0], ..., &<RHSExprs>[<n> - 1]}; switch (__kmpc_reduce{_nowait}(<loc>, <gtid>, <n>, sizeof(RedList), RedList, reduce_func, &<lock>)) { case 1: ... <LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i]); ... __kmpc_end_reduce{_nowait}(<loc>, <gtid>, &<lock>); break; case 2: ... Atomic(<LHSExprs>[i] = RedOp<i>(*<LHSExprs>[i], *<RHSExprs>[i])); ... break; default: ; } Reduction variables are a kind of a private variables, they have private copies, but initial values are chosen in accordance with the reduction operation. Differential Revision: http://reviews.llvm.org/D8915 llvm-svn: 234583
* [OPENMP] Refactoring of codegen for OpenMP directives.Alexey Bataev2015-04-101-252/+291
| | | | | | | Refactored API of OpenMPRuntime for compatibility with combined directives. Differential Revision: http://reviews.llvm.org/D8859 llvm-svn: 234564
* [OPENMP] Codegen for 'atomic update' construct.Alexey Bataev2015-03-301-3/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds atomic update codegen for the following forms of expressions: x binop= expr; x++; ++x; x--; --x; x = x binop expr; x = expr binop x; If x and expr are integer and binop is associative or x is a LHS in a RHS of the assignment expression, and atomics are allowed for type of x on the target platform atomicrmw instruction is emitted. Otherwise compare-and-swap sequence is emitted: bb: ... atomic load <x> cont: <expected> = phi [ <x>, label %bb ], [ <new_failed>, %cont ] <desired> = <expected> binop <expr> <res> = cmpxchg atomic &<x>, desired, expected <new_failed> = <res>.field1; br <res>field2, label %exit, label %cont exit: ... Differential Revision: http://reviews.llvm.org/D8536 llvm-svn: 233513
* [OPENMP] Improved codegen for implicit/explicit 'barrier' constructs.Alexey Bataev2015-03-301-9/+12
| | | | | | | Replace boolean IsExplicit parameter of OpenMPRuntime::emitBarrierCall() method by OpenMPDirectiveKind Kind for better compatibility with the runtime library. Also add processing of 'nowait' clause on worksharing directives. Differential Revision: http://reviews.llvm.org/D8659 llvm-svn: 233511
* [OPENMP] Codegen for 'copyprivate' clause ('single' directive).Alexey Bataev2015-03-231-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If there is at least one 'copyprivate' clause is associated with the single directive, the following code is generated: ``` i32 did_it = 0; \\ for 'copyprivate' clause if(__kmpc_single(ident_t *, gtid)) { SingleOpGen(); __kmpc_end_single(ident_t *, gtid); did_it = 1; \\ for 'copyprivate' clause } <copyprivate_list>[0] = &var0; ... <copyprivate_list>[n] = &varn; call __kmpc_copyprivate(ident_t *, gtid, <copyprivate_list_size>, <copyprivate_list>, <copy_func>, did_it); ... void<copy_func>(void *LHSArg, void *RHSArg) { Dst = (void * [n])(LHSArg); Src = (void * [n])(RHSArg); Dst[0] = Src[0]; ... Dst[n] = Src[n]; } ``` All list items from all 'copyprivate' clauses are gathered into single <copyprivate list> (<copyprivate_list_size> is a size in bytes of this list) and <copy_func> is used to propagate values of private or threadprivate variables from the 'single' region to other implicit threads from outer 'parallel' region. Differential Revision: http://reviews.llvm.org/D8410 llvm-svn: 232932
* [OPENMP] CodeGen of the 'linear' clause for the 'omp simd' directive.Alexander Musman2015-03-211-0/+53
| | | | | | | | | The linear variable is privatized (similar to 'private') and its value on current iteration is calculated, similar to the loop counter variables. Differential revision: http://reviews.llvm.org/D8375 llvm-svn: 232890
* [OPENMP] Enable codegen of the ‘private’ clause for ‘omp simd’ directiveAlexander Musman2015-03-161-3/+7
| | | | llvm-svn: 232353
* [OPENMP] CodeGen - 'omp for' with dynamic schedule kinds.Alexander Musman2015-03-121-16/+68
| | | | | | Differential Revision: http://reviews.llvm.org/D7138 llvm-svn: 232036
* [OPENMP] Initial codegen for 'omp sections' and 'omp section' directives.Alexey Bataev2015-03-121-21/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If only one section is found in the sections region, it is emitted just like single region. Otherwise it is emitted as a static non-chunked loop. #pragma omp sections { #pragma omp section {1} ... #pragma omp section {n} } is translated to something like i32 <iter_var> i32 <last_iter> = 0 i32 <lower_bound> = 0 i32 <upper_bound> = n-1 i32 <stride> = 1 call void @__kmpc_for_static_init_4(<loc>, i32 <gtid>, i32 34/*static non-chunked*/, i32* <last_iter>, i32* <lower_bound>, i32* <upper_bound>, i32* <stride>, i32 1/*increment always 1*/, i32 1/*chunk always 1*/) <upper_bound> = min(<upper_bound>, n-1) <iter_var> = <lb> check: br <iter_var> <= <upper_bound>, label cont, label exit continue: switch (IV) { case 0: {1}; break; ... case <NumSection> - 1: {n}; break; } ++<iter_var> br label check exit: call void @__kmpc_for_static_fini(<loc>, i32 <gtid>) Differential Revision: http://reviews.llvm.org/D8244 llvm-svn: 232021
* [OPENMP] Fix for ExprWithCleanups in 'omp atomic' constructs.Alexey Bataev2015-03-111-0/+6
| | | | | | | This patch allows using of ExprWithCleanups expressions and other complex expressions in 'omp atomic' construct Differential Revision: http://reviews.llvm.org/D8200 llvm-svn: 231905
* [OPENMP] Initial codegen for 'omp task' directive.Alexey Bataev2015-03-101-2/+29
| | | | | | | | | | | | | | | | | The task region is emmitted in several steps: Emit a call to kmp_task_t *__kmpc_omp_task_alloc(ident_t *, kmp_int32 gtid, kmp_int32 flags, size_t sizeof_kmp_task_t, size_t sizeof_shareds, kmp_routine_entry_t *task_entry). Here task_entry is a pointer to the function: kmp_int32 .omp_task_entry.(kmp_int32 gtid, kmp_task_t *tt) { TaskFunction(gtid, tt->part_id, tt->shareds); return 0; } Copy a list of shared variables to field shareds of the resulting structure kmp_task_t returned by the previous call (if any). Copy a pointer to destructions function to field destructions of the resulting structure kmp_task_t. Emit a call to kmp_int32 __kmpc_omp_task(ident_t *, kmp_int32 gtid, kmp_task_t *new_task), where new_task is a resulting structure from previous items. Differential Revision: http://reviews.llvm.org/D7560 llvm-svn: 231762
* [OPENMP] Improved code for generating debug info + generation of all OpenMP ↵Alexey Bataev2015-03-101-23/+20
| | | | | | | | | 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-20/+23
| | | | | | | | | | | | | 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-23/+20
| | | | | | | | | 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
* [OPENMP] Codegen for "#pragma omp atomic write"Alexey Bataev2015-02-271-2/+27
| | | | | | | | | | For global reg lvalue - use regular store through global register. For simple lvalue - use simple atomic store. For bitfields, vector element, extended vector elements - the original value of the whole storage (for vector elements) or of some aligned value (for bitfields) is atomically read, the part of this value for the given lvalue is modified and then use atomic compare-and-exchange operation to try to atomically write modified value (if it was not modified). Also, changes in this patch fix the bug for '#pragma omp atomic read' applied to extended vector elements. Differential Revision: http://reviews.llvm.org/D7369 llvm-svn: 230736
* [OPENMP] Fixed codegen for directives without function outlining.Alexey Bataev2015-02-261-34/+5
| | | | | | Fixed crash on codegen for directives like 'omp for', 'omp single' etc. inside of the 'omp parallel', 'omp task' etc. regions. llvm-svn: 230621
* [OPENMP] Rename methods of OpenMPRuntime class. NFC. Alexey Bataev2015-02-251-37/+34
| | | | llvm-svn: 230470
* Revert "Revert r229082 for a bit, it caused PR22577."David Majnemer2015-02-141-2/+5
| | | | | | | This reverts commit r229123. It was a red herring, the bug was present without r229082. llvm-svn: 229205
* Revert r229082 for a bit, it caused PR22577.Nico Weber2015-02-131-5/+2
| | | | llvm-svn: 229123
* MS ABI: Implement /volatile:msDavid Majnemer2015-02-131-2/+5
| | | | | | | | | | | | The /volatile:ms semantics turn volatile loads and stores into atomic acquire and release operations. This distinction is important because volatile memory operations do not form a happens-before relationship with non-atomic memory. This means that a volatile store is not sufficient for implementing a mutex unlock routine. Differential Revision: http://reviews.llvm.org/D7580 llvm-svn: 229082
* [OPENMP] Initial codegen for 'single' directive.Alexey Bataev2015-02-051-2/+7
| | | | | | | | | | | | | | | | This patch emits the following code for the single directive: #pragma omp single <body> <----> if(__kmpc_single(...)) { <body> __kmpc_end_single(...); } Differential Revision: http://reviews.llvm.org/D7045 llvm-svn: 228275
* [OPENMP] Codegen for 'taskyield' directiveAlexey Bataev2015-02-051-2/+3
| | | | | | | | | For 'taskyield' directive emit call to kmp_int32 __kmpc_omp_taskyield(ident_t *, kmp_int32 global_tid, int end_part); runtime function call with end_part arg set to 0 (it is ignored). Differential Revision: http://reviews.llvm.org/D7047 llvm-svn: 228272
* 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-2/+2
| | | | | | | | | | | | | | | | 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
* Support ‘omp for’ with static chunked schedule kind.Alexander Musman2015-01-221-2/+90
| | | | | | Differential Revision: http://reviews.llvm.org/D7006 llvm-svn: 226795
* [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: 226788
* 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
OpenPOWER on IntegriCloud