summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Renamed RefersToEnclosingLocal bitfield to RefersToCapturedVariable.Alexey Bataev2014-12-161-4/+5
| | | | | | | Bitfield RefersToEnclosingLocal of Stmt::DeclRefExprBitfields renamed to RefersToCapturedVariable to reflect latest changes introduced in commit 224323. Also renamed method Expr::refersToEnclosingLocal() to Expr::refersToCapturedVariable() and comments for constant arguments. No functional changes. llvm-svn: 224329
* [OPENMP] Bugfix for processing of global variables in OpenMP regions.Alexey Bataev2014-12-163-19/+53
| | | | | | | | 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
* Warn when attribute 'optnone' conflicts with attributes on aPaul Robinson2014-12-151-3/+4
| | | | | | different declaration of the same function. llvm-svn: 224256
* First patch with codegen of the 'omp for' directive. It implementsAlexander Musman2014-12-154-4/+351
| | | | | | | | | | | | | | | 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-153-82/+161
| | | | | | | 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
* DebugInfo: More accurate line information for placement new.David Blaikie2014-12-141-0/+3
| | | | | | | | | | | This actually came up as a break in UBSan tests (look for a follow-up commit to this one to see the UBSan test fallout) when I tried a broader fix to location information. I have some other ideas about how to do that broader change & will keep looking into it. llvm-svn: 224221
* CodeGen: Compound literals with funny types shouldn't crashDavid Majnemer2014-12-142-3/+6
| | | | | | | | | | | | | | | | | CodeGen assumed that a compound literal with array type should have a corresponding LLVM IR array type. We had two bugs in this area: - Zero sized arrays in compound literals would lead to the creation of an opaque type. This is unnecessary, we should just create an array type with a bound of zero. - Funny record types (like unions) lead to exotic IR types for compound literals. In this case, CodeGen must be prepared to deal with the possibility that it might not have an array IR type. This fixes PR21912. llvm-svn: 224219
OpenPOWER on IntegriCloud