summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprAgg.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Bugfix] Fix ICE on constexpr vector splat.George Burgess IV2016-01-131-0/+1
| | | | | | | | | | | | | In {CG,}ExprConstant.cpp, we weren't treating vector splats properly. This patch makes us treat splats more properly. Additionally, this patch adds a new cast kind which allows a bool->int cast to result in -1 or 0, instead of 1 or 0 (for true and false, respectively), so we can sanely model OpenCL bool->int casts in the AST. Differential Revision: http://reviews.llvm.org/D14877 llvm-svn: 257559
* Atomics: support __c11_* calls on _Atomic struct types.Tim Northover2015-11-091-1/+2
| | | | | | | | | | | | | When a struct's size is not a power of 2, the corresponding _Atomic() type is promoted to the nearest. We already correctly handled normal C++ expressions of this form, but direct calls to the __c11_atomic_whatever builtins ended up performing dodgy operations on the smaller non-atomic types (e.g. memcpy too much). Later optimisations removed this as undefined behaviour. This patch converts EmitAtomicExpr to allocate its temporaries at the full atomic width, sidestepping the issue. llvm-svn: 252507
* [DEBUG INFO] Emit debug info for type used in explicit cast only.Alexey Bataev2015-10-201-0/+2
| | | | | | | Currently debug info for types used in explicit cast only is not emitted. It happened after a patch for better alignment handling. This patch fixes this bug. Differential Revision: http://reviews.llvm.org/D13582 llvm-svn: 250795
* Support __builtin_ms_va_list.Charles Davis2015-09-171-2/+2
| | | | | | | | | | | | | | | | | | Summary: This change adds support for `__builtin_ms_va_list`, a GCC extension for variadic `ms_abi` functions. The existing `__builtin_va_list` support is inadequate for this because `va_list` is defined differently in the Win64 ABI vs. the System V/AMD64 ABI. Depends on D1622. Reviewers: rsmith, rnk, rjmccall CC: cfe-commits Differential Revision: http://reviews.llvm.org/D1623 llvm-svn: 247941
* Compute and preserve alignment more faithfully in IR-generation.John McCall2015-09-081-98/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
* Don't use unreachable as a placeholder, it confuses EmitBlockReid Kleckner2015-09-041-1/+3
| | | | | | | | | | This fixes an issue raised in D12412, where we generated invalid IR. Thanks to Vedant Kumar for coming up with the initial work around. Differential Revision: http://reviews.llvm.org/D12412 llvm-svn: 246880
* Implementing C99 partial re-initialization behavior (DR-253)Yunzhong Gao2015-06-101-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Based on previous discussion on the mailing list, clang currently lacks support for C99 partial re-initialization behavior: Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm This patch attempts to fix this problem. Given the following code snippet, struct P1 { char x[6]; }; struct LP1 { struct P1 p1; }; struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' }; // this example is adapted from the example for "struct fred x[]" in DR-253; // currently clang produces in l: { "\0\0x" }, // whereas gcc 4.8 produces { "fox" }; // with this fix, clang will also produce: { "fox" }; Differential Review: http://reviews.llvm.org/D5789 llvm-svn: 239446
* [CodeGen] Reuse stack space from unused function results (with more accurate ↵Leny Kholodov2015-06-081-5/+6
| | | | | | | | | | unused result detection) This patch fixes issues with unused result detection which were found in patch http://reviews.llvm.org/D9743. Differential Revision: http://reviews.llvm.org/D10042 llvm-svn: 239294
* Evaluate union cast subexpressions when the cast value is unusedReid Kleckner2015-05-201-1/+6
| | | | | | Fixes PR23597. llvm-svn: 237839
* Fix for aggregate copying of variable length arrays.Alexey Bataev2015-05-201-13/+30
| | | | | | | | | | | | | Patch fixes codegen for aggregate copying of VLAs. Currently method CodeGenFunction::EmitAggregateCopy() does not support copying of VLAs. Patch checks if the size of the type is 0, then checks if the type is actually a variable-length array. Then it calculates total length for this array and calculates total size of the array in bytes: <total number of elements in array> * aligned_sizeof(ElementType) (if copy assignment is requested). If simple copying is requested, size is calculated like: <total number of elements in array> * aligned_sizeof(ElementType) - aligned_sizeof(ElementType) + sizeof(ElementType). memcpy() is used with this calculated size of the VLA. Differential Revision: http://reviews.llvm.org/D9851 llvm-svn: 237768
* PR23373: A defaulted union copy constructor that is not trivial must still beRichard Smith2015-04-291-1/+2
| | | | | | emitted as a memcpy. llvm-svn: 236142
* InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)Justin Bogner2015-04-231-3/+3
| | | | | | | | | 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
* clang-format my last commitDavid Blaikie2015-04-051-1/+1
| | | | | | (sorry, keep forgetting that) llvm-svn: 234129
* [opaque pointer type] More GEP API migrationsDavid Blaikie2015-04-051-2/+2
| | | | | | | Looks like the VTable code in particular will need some work to pass around the pointee type explicitly. llvm-svn: 234128
* Sema: Parenthesized bound destructor member expressions can be calledDavid Majnemer2015-02-251-1/+1
| | | | | | | | | We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
* Revert "Revert r229082 for a bit, it caused PR22577."David Majnemer2015-02-141-3/+5
| | | | | | | This reverts commit r229123. It was a red herring, the bug was present without r229082. llvm-svn: 229205
* Revert r229082 for a bit, it caused PR22577.Nico Weber2015-02-131-5/+3
| | | | llvm-svn: 229123
* MS ABI: Implement /volatile:msDavid Majnemer2015-02-131-3/+5
| | | | | | | | | | | | The /volatile:ms semantics turn volatile loads and stores into atomic acquire and release operations. This distinction is important because volatile memory operations do not form a happens-before relationship with non-atomic memory. This means that a volatile store is not sufficient for implementing a mutex unlock routine. Differential Revision: http://reviews.llvm.org/D7580 llvm-svn: 229082
* DebugInfo: Refactor default arg handling into a common place (instead of ↵David Blaikie2015-02-091-5/+0
| | | | | | handling in repeatedly for aggregate, complex, and scalar types) llvm-svn: 228591
* DebugInfo: Suppress the location of instructions in aggregate default arguments.David Blaikie2015-02-091-0/+5
| | | | | | | | Matches the existing code for scalar default arguments. Complex default arguments probably need the same handling too (test/fix to that coming next). llvm-svn: 228588
* DebugInfo: Use the preferred location rather than the start location for ↵David Blaikie2015-01-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expression line info This causes things like assignment to refer to the '=' rather than the LHS when attributing the store instruction, for example. There were essentially 3 options for this: * The beginning of an expression (this was the behavior prior to this commit). This meant that stepping through subexpressions would bounce around from subexpressions back to the start of the outer expression, etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be where the actual addition occurred)). * The end of an expression. This seems to be what GCC does /mostly/, and certainly this for function calls. This has the advantage that progress is always 'forwards' (never jumping backwards - except for independent subexpressions if they're evaluated in interesting orders, etc). "x + y + z" would go "x y z" with the additions occurring at y and z after the respective loads. The problem with this is that the user would still have to think fairly hard about precedence to realize which subexpression is being evaluated or which operator overload is being called in, say, an asan backtrace. * The preferred location or 'exprloc'. In this case you get sort of what you'd expect, though it's a bit confusing in its own way due to going 'backwards'. In this case the locations would be: "x y + z +" in lovely postfix arithmetic order. But this does mean that if the op+ were an operator overload, say, and in a backtrace, the backtrace will point to the exact '+' that's being called, not to the end of one of its operands. (actually the operator overload case doesn't work yet for other reasons, but that's being fixed - but this at least gets scalar/complex assignments and other plain operators right) llvm-svn: 227027
* DebugInfo: Attribute aggregate expressions to the source location of the ↵David Blaikie2015-01-181-0/+5
| | | | | | | | | expression Just as r225956 did for scalar expressions (CGExprScalar::Visit), do the same for aggregate expressions. llvm-svn: 226388
* PR18097: Support initializing an _Atomic(T) from an object of C++ class type TRichard Smith2014-07-311-0/+10
| | | | | | | or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
* A non-trivial array-fill expression isn't necessarily a CXXConstructExpr. ItRichard Smith2014-06-131-6/+24
| | | | | | | could be an InitListExpr that runs constructors in C++11 onwards. Fixes a recent regression (introduced in r210091). llvm-svn: 210954
* Remove incorrect assertion.Richard Smith2014-06-031-4/+3
| | | | llvm-svn: 210092
* [C++11] Use 'nullptr'. CodeGen edition.Craig Topper2014-05-211-10/+11
| | | | llvm-svn: 209272
* [C++11] Replacing RecordDecl iterators field_begin() and field_end() with ↵Aaron Ballman2014-03-081-9/+4
| | | | | | iterator_range fields(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203355
* Change PGO instrumentation to compute counts in a separate AST traversal.Bob Wilson2014-02-171-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we made one traversal of the AST prior to codegen to assign counters to the ASTs and then propagated the count values during codegen. This patch now adds a separate AST traversal prior to codegen for the -fprofile-instr-use option to propagate the count values. The counts are then saved in a map from which they can be retrieved during codegen. This new approach has several advantages: 1. It gets rid of a lot of extra PGO-related code that had previously been added to codegen. 2. It fixes a serious bug. My original implementation (which was mailed to the list but never committed) used 3 counters for every loop. Justin improved it to move 2 of those counters into the less-frequently executed breaks and continues, but that turned out to produce wrong count values in some cases. The solution requires visiting a loop body before the condition so that the count for the condition properly includes the break and continue counts. Changing codegen to visit a loop body first would be a fairly invasive change, but with a separate AST traversal, it is easy to control the order of traversal. I've added a testcase (provided by Justin) to make sure this works correctly. 3. It improves the instrumentation overhead, reducing the number of counters for a loop from 3 to 1. We no longer need dedicated counters for breaks and continues, since we can just use the propagated count values when visiting breaks and continues. To make this work, I needed to make a change to the way we count case statements, going back to my original approach of not including the fall-through in the counter values. This was necessary because there isn't always an AST node that can be used to record the fall-through count. Now case statements are handled the same as default statements, with the fall-through paths branching over the counter increments. While I was at it, I also went back to using this approach for do-loops -- omitting the fall-through count into the loop body simplifies some of the calculations and make them behave the same as other loops. Whenever we start using this instrumentation for coverage, we'll need to add the fall-through counts into the counter values. llvm-svn: 201528
* Handle va_arg on struct types for the le32 target (PNaCl and Emscripten)Mark Seaborn2014-01-221-1/+5
| | | | | | | | | | | | | | | PNaCl and Emscripten can both handle va_arg IR instructions with struct type. Also add a test to cover generating a va_arg IR instruction from va_arg in C on le32 (as already handled by VisitVAArgExpr() in CGExprScalar.cpp), which was not covered by a test before. (This fixes https://code.google.com/p/nativeclient/issues/detail?id=2381) Differential Revision: http://llvm-reviews.chandlerc.com/D2539 llvm-svn: 199830
* CodeGen: Rename adjustFallThroughCount -> adjustForControlFlowJustin Bogner2014-01-131-2/+2
| | | | | | | | adjustFallThroughCount isn't a good name, and the documentation was even worse. This commit attempts to clarify what it's for and when to use it. llvm-svn: 199139
* CodeGen: Initial instrumentation based PGO implementationJustin Bogner2014-01-061-1/+7
| | | | llvm-svn: 198640
* Add front-end infrastructure now address space casts are in LLVM IR.David Tweed2013-12-111-0/+1
| | | | | | | | | | With the introduction of explicit address space casts into LLVM, there's a need to provide a new cast kind the front-end can create for C/OpenCL/CUDA and code to produce address space casts from those kinds when appropriate. Patch by Michele Scandale! llvm-svn: 197036
* Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occursNick Lewycky2013-10-021-2/+2
| | | | | | when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
* Make IgnoreParens() look through ChooseExprs.Eli Friedman2013-07-201-1/+1
| | | | | | | | | | | | | This is the same way GenericSelectionExpr works, and it's generally a more consistent approach. A large part of this patch is devoted to caching the value of the condition of a ChooseExpr; it's needed to avoid threading an ASTContext into IgnoreParens(). Fixes <rdar://problem/14438917>. llvm-svn: 186738
* Fix build.Eli Friedman2013-07-111-2/+2
| | | | | | Sorry about that. llvm-svn: 186054
* Simplify atomic load/store IRGen.Eli Friedman2013-07-111-64/+22
| | | | | | Also fixes a couple minor bugs along the way; see testcases. llvm-svn: 186049
* Simplify: we don't need any special-case lifetime extension when initializingRichard Smith2013-06-121-1/+1
| | | | | | | declarations of reference type; they're handled by the general case handling of MaterializeTemporaryExpr. llvm-svn: 183875
* PR12086, PR15117Richard Smith2013-06-121-138/+52
| | | | | | | | | | | | | | | | | | | Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
* Fix assert on temporary std::initializer_list.Richard Smith2013-05-231-1/+2
| | | | llvm-svn: 182615
* C++1y: Allow aggregates to have default initializers.Richard Smith2013-04-201-1/+8
| | | | | | | | | | | Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in CXXCtorInitializers and in InitListExprs to represent a default initializer. There's an additional complication here: because the default initializer can refer to the initialized object via its 'this' pointer, we need to make sure that 'this' points to the right thing within the evaluation. llvm-svn: 179958
* Standardize accesses to the TargetInfo in IR-gen.John McCall2013-04-161-1/+1
| | | | | | Patch by Stephen Lin! llvm-svn: 179638
* Promote atomic type sizes up to a power of two, capped byJohn McCall2013-03-071-2/+147
| | | | | | | | MaxAtomicPromoteWidth. Fix a ton of terrible bugs with _Atomic types and (non-intrinsic-mediated) loads and stores thereto. llvm-svn: 176658
* Change hasAggregateLLVMType, which conflates complex andJohn McCall2013-03-071-12/+22
| | | | | | | | | | | | | | | aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
* Evaluate compound literals directly into the result aggregateJohn McCall2013-03-071-4/+2
| | | | | | when that aggregate isn't potentially aliased. llvm-svn: 176654
* patch for PR9027 and // rdar://11861085Fariborz Jahanian2013-01-251-0/+5
| | | | | | | | | | | Title: [PR9027] volatile struct bug: member is not loaded at -O; This is caused by last flag passed to @llvm.memcpy being false, not honoring that aggregate has at least one 'volatile' data member (even though aggregate itself has not been qualified as 'volatile'. As a result, optimization optimizes away the memcpy altogether. Patch review by John MaCall (I still need to fix up a test though). llvm-svn: 173535
* Implement OpenCL event_t as Clang builtin type, including event_t related ↵Guy Benyei2013-01-201-0/+1
| | | | | | OpenCL restrictions (OpenCL 1.2 spec 6.9) llvm-svn: 172973
* Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate toChandler Carruth2013-01-021-4/+4
| | | | | | | | reflect the migration in r171366. Re-sort the #include lines to reflect the new paths. llvm-svn: 171369
* Reinstate r170806, reverted in r170835, with a fix use i1 instead of i8 for ↵Richard Smith2012-12-211-3/+3
| | | | | | a value-initialized bool! llvm-svn: 170837
* Revert r170806, "Fix some bugs where we would sometimes use 0, not -1, when ↵NAKAMURA Takumi2012-12-211-3/+3
| | | | | | | | emitting a null constant of type pointer-to-data-member." It broke stage2. llvm-svn: 170835
* Fix some bugs where we would sometimes use 0, not -1, when emitting a null ↵Richard Smith2012-12-201-3/+3
| | | | | | constant of type pointer-to-data-member. llvm-svn: 170806
OpenPOWER on IntegriCloud