summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* DebugInfo: Correct the location of EH cleanup for blocksDavid Blaikie2015-01-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | This was previously piggybacking on whatever happened to be the last location set on CGDebugInfo/DIBuilder, which was wrong (it was often the current location, such as the 'fn()' call site, not the end of the block). With my improvements to set/unset the location in a scoped manner (r225000) this went from a bad quality situation, to a crash. Fixing this goes part-way to unblocking the recommit of r225000. It's likely that any call to CodeGenFunction::StartFunction without the CurEHLocation set represents a similar bug or risk of a bug. Perhaps there are some callers that know they won't generate EH cleanups, but I'm not sure. I considered a generic catch-fix in StartFunction (just fallback to the GlobalDecl's location) but that seemed like it'd mask bugs where the EH location shouldn't be the same as the decl's location (& indeed by not using that stop-gap I found this bug). We'll see how long I can hold out on the generic catch-all. I might eventually be able to add an assertion in. llvm-svn: 225845
* [mips] Fix va_arg() for pointer types on big-endian N32.Daniel Sanders2015-01-132-6/+12
| | | | | | | | | | | | | | | | | | | | | Summary: The Mips ABI's treat pointers in the same way as integers. They are sign-extended to 32-bit for O32, and 64-bit for N32/N64. This doesn't matter for O32 and N64 where pointers are already the correct width but it does matter for big-endian N32, where pointers are 32-bit and need promoting. The caller side is already passing pointers correctly. This patch corrects the callee. Reviewers: vmedic, atanasyan Reviewed By: atanasyan Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6812 llvm-svn: 225782
* Reimplement -fsanitize-recover family of flags.Alexey Samsonov2015-01-121-38/+85
| | | | | | | | | | | | | | | | | | | | | | | | Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
* [patch][pr19848] Produce explicit comdats in clang.Rafael Espindola2015-01-125-22/+41
| | | | | | | | | | | | | | | | | | | | | | | | The llvm IR until recently had no support for comdats. This was a problem when targeting C++ on ELF/COFF as just using weak linkage would cause quite a bit of dead bits to remain on the executable (unless -ffunction-sections, -fdata-sections and --gc-sections were used). To fix the problem, llvm's codegen will just assume that any weak or linkonce that is not in an explicit comdat should be output in one with the same name as the global. This unfortunately breaks cases like pr19848 where a weak symbol is not xpected to be part of any comdat. Now that we have explicit comdats in the IR, we can finally get both cases right. This first patch just makes clang give explicit comdats to GlobalValues where t is allowed to. A followup patch to llvm will then stop implicitly producing comdats. llvm-svn: 225705
* Wrap to 80 columns. No behavior change.Nico Weber2015-01-122-5/+6
| | | | llvm-svn: 225703
* Don't use a doc comment in a function body.Nico Weber2015-01-121-3/+3
| | | | llvm-svn: 225701
* Rename RefersToCapturedVariable to RefersToEnclosingVariableOrCapture, NFCAlexey Bataev2015-01-122-7/+8
| | | | llvm-svn: 225624
* CodeGen: Simplify consecutive '%' modifiersDavid Majnemer2015-01-111-2/+3
| | | | | | LLVM the consecutive '%' modifiers are redundant, skip them. llvm-svn: 225602
* CodeGen: Simplify consecutive '&' modifiersDavid Majnemer2015-01-111-0/+5
| | | | | | LLVM the consecutive '&' modifiers are redundant, skip them. llvm-svn: 225601
* Don't emit implicit template instantiations eagerly (PR21718)Hans Wennborg2015-01-102-17/+41
| | | | | | | | | | | | | | Their linkage can change if they are later explicitly instantiated. We would previously emit such functions eagerly (as opposed to lazily on first use) if they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the explicit instantiation. This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method with two new ones: MustBeEmitted() and MayBeEmittedEagerly(). Differential Revision: http://reviews.llvm.org/D6674 llvm-svn: 225570
* Revert "DebugInfo: Generalize debug info location handling" and related commitsDavid Blaikie2015-01-0916-117/+209
| | | | | | | | | | | | 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
* Driver: begin threading frontend support for SymbolRewriterSaleem Abdulrasool2015-01-091-0/+14
| | | | | | | | | | Allow blessed access to the symbol rewriter from the driver. Although the symbol rewriter could be invoked through tools like opt and llc, it would not accessible from the frontend. This allows us to read the rewrite map files in the frontend rather than the backend and enable symbol rewriting for actually performing the symbol interpositioning. llvm-svn: 225504
* InstrProf: Don't emit counter increments in dead codeJustin Bogner2015-01-091-0/+2
| | | | | | | | | We were previously emitting counter increments even if we didn't have an insertion point, which would result in a CallInst with no parent. This leads to a crash, as in pr22166, if we try to do GlobalDCE. llvm-svn: 225495
* Revert r225085, it caused PR22096.Nico Weber2015-01-072-0/+11
| | | | | | | | PR22096 has several test cases that assert that look fairly different. I'm adding one of those as an automated test, but when relanding the other cases should probably be checked as well. llvm-svn: 225361
* Debug info: pass in the correct size for a pointer to a member function.Adrian Prantl2015-01-071-2/+2
| | | | | | This corrects a bug I introduced in r224781. llvm-svn: 225359
* Fix comment typo.Nico Weber2015-01-071-1/+1
| | | | llvm-svn: 225340
* Add __builtin_amdgpu_classMatt Arsenault2015-01-061-0/+3
| | | | llvm-svn: 225314
* R600: Handle amdgcn tripleTom Stellard2015-01-062-0/+3
| | | | | | For now there is no difference between amdgcn and r600. llvm-svn: 225294
* DebugInfo: Provide a less subtle way to set the debug location of simple ret ↵David Blaikie2015-01-024-12/+23
| | | | | | | | instructions un-XFAILing the test XFAIL'd in r225086 after it regressed in r225083. llvm-svn: 225090
* DebugInfo: Remove some now-unnecessary location handling around function ↵David Blaikie2015-01-022-11/+0
| | | | | | | | | | | | | | arguments. r225000 generalized debug info line info handling for expressions such that this code is no longer necessary. This removes the last use of CGDebugInfo::getLocation, but not all the uses of CGDebugInfo::CurLoc, which is still used internally in CGDebugInfo. I'd like to do away with all of that & might succeed after a few more patches. llvm-svn: 225085
* DebugInfo: Fix cases where location failed to be updated after r225000David Blaikie2015-01-022-15/+1
| | | | | | | | | | | | | The optimization (that appears to have been here since the earliest implementation (r50848) & has become more complicated over the years) to avoid recreating the debugloc if it would be the same was out of date because ApplyDebugLocation was not re-updating the CurLoc/PrevLoc. This optimization doesn't look terribly beneficial/necessary, so I'm removing it - if it turns up in benchmarks, I'm happy to reconsider/reimplement this with justification, but for now it just seems to add complexity/problems. llvm-svn: 225083
* CodeGen: Don't crash when a lambda uses a local constexpr variableDavid Majnemer2015-01-011-16/+16
| | | | | | | | | | | The DeclRefExpr might be for a variable initialized by a constant expression which hasn't been ODR used. Emit the initializer for the variable instead of trying to capture the variable itself. This fixes PR22071. llvm-svn: 225060
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-3015-184/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add a public accessor for GlobalCtors in CodeGenModuleKeno Fischer2014-12-301-0/+5
| | | | | | | | | | | | | Summary: In a JIT context it is useful to be able to access the GlobalCtors and especially clear them once they have been emitted and called. This adds a public method to be able to access the list. Subscribers: yaron.keren, cfe-commits Differential Revision: http://reviews.llvm.org/D6790 llvm-svn: 224982
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-2915-92/+184
| | | | | | | | | Asserting when building compiler-rt when using a GCC host compiler. Reverting while I investigate. This reverts commit r224941. llvm-svn: 224970
* PR22051: Missing debug location on calls in dtor thunks in Windows.David Blaikie2014-12-291-1/+1
| | | | llvm-svn: 224963
* Use std::find_if instead of manual loop.David Blaikie2014-12-291-8/+4
| | | | llvm-svn: 224960
* Add an assertion to verify a container is non-empty before calling 'back()'David Blaikie2014-12-291-0/+1
| | | | | | | This would've helped stabilize/deflake some failures that were seen after some recent changes. llvm-svn: 224943
* Reapply "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-2915-184/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* CodeGen: Optimize emssion of zeroinitialzied arraysDavid Majnemer2014-12-281-12/+24
| | | | | | | | | Create an ConstantAggregateZero upfront if we see that it is viable. This saves us from having to manually push_back each and every initializer and then looping back over them to determine if they are 'null'. llvm-svn: 224908
* [x86] Add the (v)cmpps/pd/ss/sd builtins to match gcc. Use them in the sse ↵Craig Topper2014-12-271-2/+150
| | | | | | | | | | intrinsic files. This still lower to the same intrinsics as before. This is preparation for bounds checking the immediate on the avx version of the builtin so we don't pass illegal immediates into the backend. Since SSE uses a smaller size immediate its not possible to bounds check when using a shared builtin. Rather than creating a clang specific builtin for the different immediate, I decided (after consulting with Chandler) that it was better to match gcc. llvm-svn: 224879
* Initialize BackendConsumer::Context in constructor.Yaron Keren2014-12-251-1/+1
| | | | llvm-svn: 224836
* Initialize CodeGeneratorImpl::Ctx in constructor.Yaron Keren2014-12-251-1/+1
| | | | llvm-svn: 224835
* Debug Info: Pass the pointer size into createMemberPointerType().Adrian Prantl2014-12-231-2/+3
| | | | | | Paired commit with LLVM. llvm-svn: 224781
* Tweak the assert in ModuleBuilder from r224533 (PR21989)Hans Wennborg2014-12-191-2/+3
| | | | | | | Turns out there will be left-over deferred inline methods if there have been errors, because in that case HandleTopLevelDecl bails out early. llvm-svn: 224649
* Fix an address space id reset with array decay'sPekka Jaaskelainen2014-12-191-1/+2
| | | | | | | | | | implicit conversion. The issue was produced with OpenCL C code that called a function with a constant string literal argument. llvm-svn: 224592
* Fix a typo.Adrian Prantl2014-12-191-1/+1
| | | | llvm-svn: 224557
* ModuleBuilder: assert that all deferred inline method defs get handledHans Wennborg2014-12-181-4/+7
| | | | | | | While we're here, also move the declaration of DeferredInlineMethodDefinitions closer to the other member vars and make it a SmallVector. NFC. llvm-svn: 224533
* [Objective-C]. Patch to unify code generation for ObjCMsgSend and ObjCBoxedExpr.Fariborz Jahanian2014-12-181-6/+2
| | | | | | Patch by Alex Denisov. NFC. llvm-svn: 224525
* 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
* Update for llvm front end change and use the TargetOptions structEric Christopher2014-12-181-0/+1
| | | | | | for ABI. llvm-svn: 224493
* CGDebugInfo: Use DIBuilder API for self-referencing DICompositeTypesDuncan P. N. Exon Smith2014-12-181-9/+10
| | | | | | | | | | | Use new `DIBuilder` API from LLVM r224482 to mutate `DICompositeType`s, rather than changing them directly. This allows `DIBuilder` to track otherwise orphaned cycles when `CollectContainingType()` creates a self-reference. Fixes PR21941. llvm-svn: 224483
* InstrProf: Simplify/reduce state in CoverageMapping (NFC)Justin Bogner2014-12-171-38/+2
| | | | | | | | This state object makes things harder to reason about and isn't really useful, since we can just emit the mappings before the state changes rather than holding on to it. llvm-svn: 224476
* Revert "Put static local variables of inline functions in the function comdat."Rafael Espindola2014-12-171-4/+2
| | | | | | | | | This reverts commit r224369. Thanks to Reid Kleckner for pointing out that we need a bigger gun to fix this case. llvm-svn: 224475
* Revert "DebugInfo: Generalize debug info location handling"David Blaikie2014-12-1715-92/+184
| | | | | | | | | Fails an ASan bootstrap - I'll try to reproduce locally & sort that out before recommitting. This reverts commit r224385. llvm-svn: 224441
* CodeGen: implement __emit intrinsicSaleem Abdulrasool2014-12-171-0/+22
| | | | | | | | | | | | | | | For MSVC compatibility, add the `__emit' builtin. This is used in the Windows SDK headers, and must therefore be implemented as a builtin rather than an intrinsic. The `__emit' builtin provides a mechanism to emit a 16-bit opcode instruction into the stream. The value must be a compile time constant expression. No guarantees are made about the CPU and memory states after the execution of the instruction. Due to the unchecked nature of the builtin, only support this on Windows on ARM. llvm-svn: 224438
* s/ScheduleKind/SchedKind/ in \param. [-Wdocumentation]NAKAMURA Takumi2014-12-171-1/+1
| | | | llvm-svn: 224431
* PR21909: Don't try (and crash) to generate debug info for explicit ↵David Blaikie2014-12-161-1/+2
| | | | | | instantiations of explicit specializations. llvm-svn: 224394
* DebugInfo: Generalize debug info location handlingDavid Blaikie2014-12-1615-184/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Put static local variables of inline functions in the function comdat.Rafael Espindola2014-12-161-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | The variable (and the GV) is only ever used if the function is. Putting it in the function's comdat make it easier for the linker to discard them. The motivating example is struct S { static const int x; }; // const int S::x = 42; inline const int *f() { static const int y = S::x; return &y; } const int *g() { return f(); } With S::x commented out, _ZZ1fvE1y is a variable with a guard variable that is initialized by f. With S::x present, _ZZ1fvE1y is a constant. llvm-svn: 224369
OpenPOWER on IntegriCloud