aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenFunction.h
AgeCommit message (Collapse)AuthorFilesLines
2015-06-25[CUDA] Implemented __nvvm_atom_*_gen_* builtins.Artem Belevich1-0/+1
Integer variants are implemented as atomicrmw or cmpxchg instructions. Atomic add for floating point (__nvvm_atom_add_gen_f()) is implemented as a call to an overloaded @llvm.nvvm.atomic.load.add.f32.* LVVM intrinsic. Differential Revision: http://reviews.llvm.org/D10666 llvm-svn: 240669
2015-06-24Proper changing/restoring for CapturedStmtInfo, NFC.Alexey Bataev1-0/+14
Added special RAII class for proper values changing/restoring in CodeGenFunction::CapturedStmtInfo. llvm-svn: 240517
2015-06-19AMDGPU: Fix places missed in renameMatt Arsenault1-1/+1
llvm-svn: 240148
2015-06-19Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.Peter Collingbourne1-3/+13
This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 llvm-svn: 240109
2015-06-18[OPENMP] Support for '#pragma omp taskgroup' directive.Alexey Bataev1-0/+1
Added parsing, sema analysis and codegen for '#pragma omp taskgroup' directive (OpenMP 4.0). The code for directive is generated the following way: #pragma omp taskgroup <body> void __kmpc_taskgroup(<loc>, thread_id); <body> void __kmpc_end_taskgroup(<loc>, thread_id); llvm-svn: 240011
2015-06-18[OPENMP] Add support for 'omp parallel for' directive.Alexey Bataev1-0/+5
Codegen for this directive is a combined codegen for 'omp parallel' region with 'omp for simd' region inside. Clauses are supported. llvm-svn: 240006
2015-06-18[OPENMP] Add support for 'omp for simd' directive.Alexey Bataev1-1/+3
Added codegen for combined 'omp for simd' directives, that is a combination of 'omp for' directive followed by 'omp simd' directive. Includes support for all clauses. llvm-svn: 239990
2015-06-17[OPENMP] Code reformatting for omp simd codegen, NFC.Alexey Bataev1-1/+0
llvm-svn: 239889
2015-06-16[OPENMP] Support lastprivate clause in omp simd directive.Alexey Bataev1-2/+2
Added codegen for lastprivate clauses within simd loop-based directives. llvm-svn: 239813
2015-06-16[OPENMP] Remove last iteration separation for loop-based constructs.Alexey Bataev1-2/+1
Previously the last iteration for simd loop-based OpenMP constructs were generated as a separate code. This feature is not required and codegen is simplified. llvm-svn: 239810
2015-06-09Revert "Re-land r236052, "[SEH] Add 32-bit lowering code for __try""Reid Kleckner1-17/+3
This reverts commit r239415. This was committed accidentally, LLVM isn't ready for this. llvm-svn: 239417
2015-06-09Re-land r236052, "[SEH] Add 32-bit lowering code for __try"Reid Kleckner1-3/+17
This reverts r236167. LLVM should be ready for this now. llvm-svn: 239415
2015-05-30ubsan: Check for null pointers given to certain builtins, suchNuno Lopes1-0/+5
as memcpy, memset, memmove, and bzero. Reviewed by: Richard Smith Differential Revision: http://reviews.llvm.org/D9673 llvm-svn: 238657
2015-05-29wip: Remove some unused functionsJustin Bogner1-7/+0
llvm-svn: 238538
2015-05-20[OPENMP] Fix codegen for ordered loop directives.Alexey Bataev1-3/+3
loops with ordered clause must be generated the same way as dynamic loops, but with static scheduleing. llvm-svn: 237788
2015-05-15[OPENMP] Fixed bug in atomic update/capture/write constructs.Alexey Bataev1-1/+1
Fixed a bug with codegen for destination atomic l-value with padding and junk in this padding bytes. llvm-svn: 237422
2015-05-11Unify sanitizer kind representation between the driver and the rest of the ↵Peter Collingbourne1-1/+1
compiler. No functional change. Differential Revision: http://reviews.llvm.org/D9618 llvm-svn: 237055
2015-05-02InstrProf: Cede ownership of createProfileWeights to CGFJustin Bogner1-0/+6
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
2015-04-30Revert most of r236271, leaving only the datalayout change in ↵Reid Kleckner1-17/+3
lib/Basic/Targets.cpp llvm-svn: 236274
2015-04-30Use 4 byte preferred aggregate alignment in datalayout on x86 Win32Reid Kleckner1-3/+17
llvm-svn: 236271
2015-04-29Revert r236128, LLVM isn't falling back in the right wayReid Kleckner1-17/+3
llvm-svn: 236167
2015-04-29Re-land r236052, the linker errors were fixed by LLVM r236123Reid Kleckner1-3/+17
Basic __finally blocks don't cause linker errors anymore (although they are miscompiled). llvm-svn: 236128
2015-04-29Revert r236052, it caused linker errors when building 32-bit applications.Nico Weber1-17/+3
llvm-svn: 236082
2015-04-28[SEH] Add 32-bit lowering code for __tryReid Kleckner1-3/+17
This is just the clang-side of 32-bit SEH. LLVM still needs work, and it will determinstically fail to compile until it's feature complete. On x86, all outlined handlers have no parameters, but they do implicitly take the EBP value passed in and use it to address locals of the parent frame. We model this with llvm.frameaddress(1). This works (mostly), but __finally block inlining can break it. For now, we apply the 'noinline' attribute. If we really want to inline __finally blocks on 32-bit x86, we should teach the inliner how to untangle frameescape and framerecover. Promote the error diagnostic from codegen to sema. It now rejects SEH on non-Windows platforms. LLVM doesn't implement SEH on non-x86 Windows platforms, but there's nothing preventing it. llvm-svn: 236052
2015-04-23InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)Justin Bogner1-7/+27
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
2015-04-23[OPENMP] Codegen for 'atomic capture'.Alexey Bataev1-1/+3
Adds codegen for 'atomic capture' constructs with the following forms of expressions/statements: v = x binop= expr; v = x++; v = ++x; v = x--; v = --x; v = x = x binop expr; v = x = expr binop x; {v = x; x = binop= expr;} {v = x; x++;} {v = x; ++x;} {v = x; x--;} {v = x; --x;} {x = x binop expr; v = x;} {x binop= expr; v = x;} {x++; v = x;} {++x; v = x;} {x--; v = x;} {--x; v = x;} {x = x binop expr; v = x;} {x = expr binop x; v = x;} {v = x; x = expr;} 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. Update of 'v' is not required to be be atomic with respect to the read or write of the 'x'. 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: atomic store <old/new x>, <v> ... Differential Revision: http://reviews.llvm.org/D9049 llvm-svn: 235573
2015-04-22Revert "Revert r234581, it might have caused a few miscompiles in Chromium."David Majnemer1-0/+3
This reverts commit r234700. It turns out that the lifetime markers were not the cause of Chromium failing but a bug which was uncovered by optimizations exposed by the markers. llvm-svn: 235553
2015-04-22[OPENMP] Codegen for 'ordered' directive.Alexey Bataev1-4/+15
Add codegen for 'ordered' directive: __kmpc_ordered(ident_t *, gtid); <associated statement>; __kmpc_end_ordered(ident_t *, gtid); Also for 'for' directives with the dynamic scheduling and an 'ordered' clause added a call to '__kmpc_dispatch_fini_(4|8)[u]()' function after increment expression for loop control variable: while(__kmpc_dispatch_next(&LB, &UB)) { idx = LB; while (idx <= UB) { BODY; ++idx; __kmpc_dispatch_fini_(4|8)[u](); // For ordered loops only. } // inner loop } Differential Revision: http://reviews.llvm.org/D9070 llvm-svn: 235496
2015-04-16[OPENMP] Codegen for 'copyin' clause in 'parallel' directive.Alexey Bataev1-0/+12
Emits the following code for the clause at the beginning of the outlined function for implicit threads: if (<not a master thread>) { ... <thread local copy of var> = <master thread local copy of var>; ... } <sync point>; Checking for a non-master thread is performed by comparing of the address of the thread local variable with the address of the master's variable. Master thread always uses original variables, so you always know the address of the variable in the master thread. Differential Revision: http://reviews.llvm.org/D9026 llvm-svn: 235075
2015-04-16[OPENMP] Codegen for 'lastprivate' clause in 'for' directive.Alexey Bataev1-1/+26
#pragma omp for lastprivate(<var>) for (i = a; i < b; ++b) <BODY>; This construct is translated into something like: <last_iter> = alloca i32 <lastprivate_var> = alloca <type> <last_iter> = 0 ; No initializer for simple variables or a default constructor is called for objects. ; For arrays perform element by element initialization by the call of the default constructor. ... OMP_FOR_START(...,<last_iter>, ..); sets <last_iter> to 1 if this is the last iteration. <BODY> ... OMP_FOR_END if (<last_iter> != 0) { <var> = <lastprivate_var> ; Update original variable with the lastprivate value. } call __kmpc_cancel_barrier() ; an implicit barrier to avoid possible data race. Differential Revision: http://reviews.llvm.org/D8658 llvm-svn: 235074
2015-04-15[OPENMP] Codegen for 'firstprivate' clause in 'for' directive.Alexey Bataev1-1/+1
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
2015-04-14Reland r234613 (and follow-ups 234614, 234616, 234618)Reid Kleckner1-17/+13
The frameescape intrinsic cannot be inlined, so I fixed the inliner in r234937. This should address PR23216. llvm-svn: 234942
2015-04-14[OPENMP] Fixed codegen for arrays in 'copyprivate' clause.Alexey Bataev1-3/+27
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
2015-04-14[OPENMP] Initial codegen for 'parallel sections' directive.Alexey Bataev1-4/+5
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
2015-04-13Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.Nico Weber1-13/+17
llvm-svn: 234789
2015-04-13Revert r234786, it contained a bunch of stuff I did not mean to commit.Nico Weber1-17/+13
llvm-svn: 234787
2015-04-13Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.Nico Weber1-13/+17
llvm-svn: 234786
2015-04-11Revert r234581, it might have caused a few miscompiles in Chromium.Nico Weber1-3/+0
If the revert helps, I'll get a repro this Monday. Else I'll put the change back in. llvm-svn: 234700
2015-04-10[SEH] Re-land r234532, but use internal linkage for all SEH helpersReid Kleckner1-17/+13
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
2015-04-10[OPENMP] Codegen for 'reduction' clause in 'parallel' directive.Alexey Bataev1-0/+29
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
2015-04-10Remove threshold for inserting lifetime markers for named temporariesArnaud A. de Grandmaison1-0/+3
Now that TailRecursionElimination has been fixed with r222354, the threshold on size for lifetime marker insertion can be removed. This only affects named temporary though, as the patch for unnamed temporaries is still in progress. My previous commit (r222993) was not handling debuginfo correctly, but this could only be seen with some asan tests. Basically, lifetime markers are just instrumentation for the compiler's usage and should not affect debug information; however, the cleanup infrastructure was assuming it contained only destructors, i.e. actual code to be executed, and was setting the breakpoint for the end of the function to the closing '}', and not the return statement, in order to show some destructors have been called when leaving the function. This is wrong when the cleanups are only lifetime markers, and this is now fixed. llvm-svn: 234581
2015-04-10[OPENMP] Refactoring of codegen for OpenMP directives.Alexey Bataev1-4/+5
Refactored API of OpenMPRuntime for compatibility with combined directives. Differential Revision: http://reviews.llvm.org/D8859 llvm-svn: 234564
2015-04-10Revert r234532 for a bit, it very likely caused http://crbug.com/475768Nico Weber1-13/+17
llvm-svn: 234563
2015-04-09[SEH] Outline finally blocks using the new variable capture supportReid Kleckner1-17/+13
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
2015-04-08Reland "[SEH] Implement filter capturing in CodeGen"Reid Kleckner1-0/+10
The test should be fixed. It was failing in NDEBUG builds due to a missing '*' character in a regex. In asserts builds, the pattern matched a single digit value, which became a double digit value in NDEBUG builds. Go figure. This reverts commit r234261. llvm-svn: 234447
2015-04-07Revert "[SEH] Implement filter capturing in CodeGen"Daniel Jasper1-10/+0
Test fails: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/3182/ llvm-svn: 234306
2015-04-06[SEH] Implement filter capturing in CodeGenReid Kleckner1-0/+10
While capturing filters aren't very common, we'd like to outline __finally blocks in the frontend to simplify -O0 EH preparation and reduce code size. Finally blocks are usually have captures, and this is the first step towards that. Currently we don't support capturing 'this' or VLAs. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D8825 llvm-svn: 234261
2015-04-05[opaque pointer type] More GEP API migrationsDavid Blaikie1-3/+4
Looks like the VTable code in particular will need some work to pass around the pointee type explicitly. llvm-svn: 234128
2015-04-04[opaque pointer type] more GEP API migrationsDavid Blaikie1-1/+2
llvm-svn: 234097
2015-04-01[SystemZ] Support transactional execution on zEC12Ulrich Weigand1-0/+1
The zEC12 provides the transactional-execution facility. This is exposed to users via a set of builtin routines on other compilers. This patch adds clang support to enable those builtins. In partciular, the patch: - enables the transactional-execution feature by default on zEC12 - allows to override presence of that feature via the -mhtm/-mno-htm options - adds a predefined macro __HTM__ if the feature is enabled - adds support for the transactional-execution GCC builtins - adds Sema checking to verify the __builtin_tabort abort code - adds the s390intrin.h header file (for GCC compatibility) - adds s390 sections to the htmintrin.h and htmxlintrin.h header files Since this is first use of target-specific intrinsics on the platform, the patch creates the include/clang/Basic/BuiltinsSystemZ.def file and hooks it up in TargetBuiltins.h and lib/Basic/Targets.cpp. An associated LLVM patch adds the required LLVM IR intrinsics. For reference, the transactional-execution instructions are documented in the z/Architecture Principles of Operation for the zEC12: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/download/DZ9ZR009.pdf The associated builtins are documented in the GCC manual: http://gcc.gnu.org/onlinedocs/gcc/S_002f390-System-z-Built-in-Functions.html The htmxlintrin.h intrinsics provided for compatibility with the IBM XL compiler are documented in the "z/OS XL C/C++ Programming Guide". llvm-svn: 233804