summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CodeGenFunction.h
Commit message (Collapse)AuthorAgeFilesLines
...
* [SEH] Outline finally blocks using the new variable capture supportReid Kleckner2015-04-091-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
* Reland "[SEH] Implement filter capturing in CodeGen"Reid Kleckner2015-04-081-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
* Revert "[SEH] Implement filter capturing in CodeGen"Daniel Jasper2015-04-071-10/+0
| | | | | | | Test fails: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/3182/ llvm-svn: 234306
* [SEH] Implement filter capturing in CodeGenReid Kleckner2015-04-061-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
* [opaque pointer type] More GEP API migrationsDavid Blaikie2015-04-051-3/+4
| | | | | | | Looks like the VTable code in particular will need some work to pass around the pointee type explicitly. llvm-svn: 234128
* [opaque pointer type] more GEP API migrationsDavid Blaikie2015-04-041-1/+2
| | | | llvm-svn: 234097
* [SystemZ] Support transactional execution on zEC12Ulrich Weigand2015-04-011-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
* [OPENMP] Codegen for 'atomic update' construct.Alexey Bataev2015-03-301-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Codegen for 'copyprivate' clause ('single' directive).Alexey Bataev2015-03-231-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement bad cast checks using control flow integrity information.Peter Collingbourne2015-03-141-0/+10
| | | | | | | | | | | This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class. Differential Revision: http://reviews.llvm.org/D8312 llvm-svn: 232241
* Disambiguate call for GCC.Benjamin Kramer2015-03-121-1/+1
| | | | llvm-svn: 232122
* CodeGen: Base the conditional cleanup machinery on variadic templatesBenjamin Kramer2015-03-121-69/+11
| | | | | | | | | | | This is complicated by the fact that we can't simply use side-effecting calls in an argument list without losing all guarantees about the order they're emitted. To keep things deterministic we use tuples and brace initialization, which thankfully guarantees evaluation order. No functionality change intended. llvm-svn: 232121
* [OPENMP] Initial codegen for 'omp sections' and 'omp section' directives.Alexey Bataev2015-03-121-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* MS ABI: Implement support for throwing a C++ exceptionDavid Majnemer2015-03-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Throwing a C++ exception, under the MS ABI, is implemented using three components: - ThrowInfo structure which contains information like CV qualifiers, what destructor to call and a pointer to the CatchableTypeArray. - In a significant departure from the Itanium ABI, copying by-value occurs in the runtime and not at the catch site. This means we need to enumerate all possible types that this exception could be caught as and encode the necessary information to convert from the exception object's type to the catch handler's type. This includes complicated derived to base conversions and the execution of copy-constructors. N.B. This implementation doesn't support the execution of a copy-constructor from within the runtime for now. Adding support for that functionality is quite difficult due to things like default argument expressions which may evaluate arbitrary code hiding in the copy-constructor's parameters. Differential Revision: http://reviews.llvm.org/D8066 llvm-svn: 231328
* [OPENMP] Fixed codegen for directives without function outlining.Alexey Bataev2015-02-261-5/+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
* Implement Control Flow Integrity for virtual calls.Peter Collingbourne2015-02-201-0/+3
| | | | | | | | | | | | | | | This patch introduces the -fsanitize=cfi-vptr flag, which enables a control flow integrity scheme that checks that virtual calls take place using a vptr of the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst file. It also introduces the -fsanitize=cfi flag, which is currently a synonym for -fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented in Clang. Differential Revision: http://reviews.llvm.org/D7424 llvm-svn: 230055
* Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for ↵Aaron Ballman2015-02-151-8/+8
| | | | | | requiring the macro. NFC; Clang edition. llvm-svn: 229339
* Removing LLVM_EXPLICIT, as MSVC 2012 was the last reason for requiring the ↵Aaron Ballman2015-02-151-1/+1
| | | | | | macro. NFC; Clang edition. llvm-svn: 229336
* Revert "Revert r229082 for a bit, it caused PR22577."David Majnemer2015-02-141-0/+10
| | | | | | | 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-10/+0
| | | | llvm-svn: 229123
* MS ABI: Implement /volatile:msDavid Majnemer2015-02-131-0/+10
| | | | | | | | | | | | 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
* SEH: Use the SEHTryEpilogueStack instead of a separate boolReid Kleckner2015-02-121-3/+3
| | | | | | We don't need a bool to track this now that we have a stack for it. llvm-svn: 228982
* [ms] Implement codegen for __leave.Nico Weber2015-02-121-0/+1
| | | | | | Reviewed at http://reviews.llvm.org/D7575 llvm-svn: 228977
* Fix typoo.Richard Smith2015-02-121-2/+2
| | | | llvm-svn: 228963
* Wrap to 80 columns. No behavior change.Nico Weber2015-02-111-1/+2
| | | | llvm-svn: 228880
* Add the 'noinline' attribute to call sites within __try bodiesReid Kleckner2015-02-111-0/+3
| | | | | | | LLVM doesn't support non-call exceptions, so inlining makes it harder to catch such asynchronous exceptions. llvm-svn: 228876
* Emit landing pads for SEH even if nounwind is presentReid Kleckner2015-02-111-0/+5
| | | | | | | Disabling exceptions applies nounwind to lots of functions. SEH catches asynch exceptions, so emit the landing pad anyway. llvm-svn: 228769
* Implement IRGen for SEH __finally and AbnormalTerminationReid Kleckner2015-02-041-2/+20
| | | | | | | | | | | Previously we would simply double-emit the body of the __finally block, but that doesn't work when it contains any kind of Decl, which we can't double emit. This fixes that by emitting the block once and branching into a shared code region and then branching back out. llvm-svn: 228222
* DebugInfo: Attribute cleanup code to the end of the scope, not the end of ↵David Blaikie2015-02-041-1/+4
| | | | | | | | | | | | | | | | | | the function. Now if you break on a dtor and go 'up' in your debugger (or you get an asan failure in a dtor) during an exception unwind, you'll have more context. Instead of all dtors appearing to be called from the '}' of the function, they'll be attributed to the end of the scope of the variable, the same as the non-exceptional dtor call. This doesn't /quite/ remove all uses of CurEHLocation (which might be nice to remove, for a few reasons) - it's still used to choose the location for some other work in the landing pad. It'd be nice to attribute that code to the same location as the exception calls within the block and to remove CurEHLocation. llvm-svn: 228181
* CodeGen: Copy-ctorm must obey the destination's alignment requirementDavid Majnemer2015-02-031-0/+9
| | | | | | | | We would synthesize memcpy intrinsics when emitting calls to trivial C++ constructors but we wouldn't take into account the alignment of the destination. llvm-svn: 228061
* Support ‘omp for’ with static chunked schedule kind.Alexander Musman2015-01-221-0/+6
| | | | | | Differential Revision: http://reviews.llvm.org/D7006 llvm-svn: 226795
* Initial support for Win64 SEH IR emissionReid Kleckner2015-01-221-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lowering looks a lot like normal EH lowering, with the exception that the exceptions are caught by executing filter expression code instead of matching typeinfo globals. The filter expressions are outlined into functions which are used in landingpad clauses where typeinfo would normally go. Major aspects that still need work: - Non-call exceptions in __try bodies won't work yet. The plan is to outline the __try block in the frontend to keep things simple. - Filter expressions cannot use local variables until capturing is implemented. - __finally blocks will not run after exceptions. Fixing this requires work in the LLVM SEH preparation pass. The IR lowering looks like this: // C code: bool safe_div(int n, int d, int *r) { __try { *r = normal_div(n, d); } __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) { return false; } return true; } ; LLVM IR: define i32 @filter(i8* %e, i8* %fp) { %ehptrs = bitcast i8* %e to i32** %ehrec = load i32** %ehptrs %code = load i32* %ehrec %matches = icmp eq i32 %code, i32 u0xC0000094 %matches.i32 = zext i1 %matches to i32 ret i32 %matches.i32 } define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) { %rr = invoke i32 @normal_div(i32 %n, i32 %d) to label %normal unwind to label %lpad normal: store i32 %rr, i32* %r ret i1 1 lpad: %ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*) %ehptr = extractvalue {i8*, i32} %ehvals, i32 0 %sel = extractvalue {i8*, i32} %ehvals, i32 1 %filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*)) %matches = icmp eq i32 %sel, %filter_sel br i1 %matches, label %eh.except, label %eh.resume eh.except: ret i1 false eh.resume: resume } Reviewers: rjmccall, rsmith, majnemer Differential Revision: http://reviews.llvm.org/D5607 llvm-svn: 226760
* DebugInfo: Remove forced column-info workaround for inlined callsDavid Blaikie2015-01-211-4/+3
| | | | | | | | | | | | | | | | | This workaround was to provide unique call sites to ensure LLVM's inline debug info handling would properly unique two calls to the same function on the same line. Instead, this has now been fixed in LLVM (r226736) and the workaround here can be removed. Originally committed in r176895, but this isn't a straight revert due to all the changes since then. I just searched for anything ForcedColumn* related and removed them. We could test this - but it didn't strike me as terribly valuable once we're no longer adding this workaround everything just works as expected & it's no longer a special case to test for. llvm-svn: 226738
* Add comment after API changes in r225090David Blaikie2015-01-181-2/+4
| | | | | | Code review suggestion by Eric Christopher. llvm-svn: 226395
* Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info ↵David Blaikie2015-01-141-25/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Sink a parameter into the callee since it's always the same expression in ↵David Blaikie2015-01-141-3/+1
| | | | | | terms of another parameter llvm-svn: 225856
* Revert "DebugInfo: Generalize debug info location handling" and related commitsDavid Blaikie2015-01-091-7/+25
| | | | | | | | | | | | 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
* DebugInfo: Provide a less subtle way to set the debug location of simple ret ↵David Blaikie2015-01-021-1/+1
| | | | | | | | instructions un-XFAILing the test XFAIL'd in r225086 after it regressed in r225083. llvm-svn: 225090
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-301-24/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+24
| | | | | | | | | 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-24/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix for PR21915: assert on multidimensional VLA in function arguments.Alexey Bataev2014-12-181-22/+7
| | | | | | | Fixed assertion on type checking for arguments and parameters on function call if arguments are pointers to VLA Differential Revision: http://reviews.llvm.org/D6655 llvm-svn: 224504
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-171-6/+24
| | | | | | | | | 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-24/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+2
| | | | | | | | 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-1/+6
| | | | | | | | | | | | | | | 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
* Bugfix for Codegen of atomic load/store/other ops.Alexey Bataev2014-12-151-0/+6
| | | | | | | Currently clang fires assertions on x86-64 on any atomic operations for long double operands. Patch fixes codegen for such operations. Differential Revision: http://reviews.llvm.org/D6499 llvm-svn: 224230
* Implement the __builtin_call_with_static_chain GNU extension.Peter Collingbourne2014-12-121-2/+4
| | | | | | | | | | | | | | | | The extension has the following syntax: __builtin_call_with_static_chain(Call, Chain) where Call must be a function call expression and Chain must be of pointer type This extension performs a function call Call with a static chain pointer Chain passed to the callee in a designated register. This is useful for calling foreign language functions whose ABI uses static chain pointers (e.g. to implement closures). Differential Revision: http://reviews.llvm.org/D6332 llvm-svn: 224167
* DebugInfo: Correct the location of initializations of auto.David Blaikie2014-12-091-2/+1
| | | | llvm-svn: 223839
* DebugInfo: Emit the correct location for initialization of a complex variableDavid Blaikie2014-12-091-2/+4
| | | | | | Especially useful for sanitizer reports. llvm-svn: 223825
OpenPOWER on IntegriCloud