summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprAgg.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-1/+1
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* A step towards sorting out handling of triviality of special members in C++11.Richard Smith2012-11-161-2/+2
| | | | | | | | | | | | | | Separate out the notions of 'has a trivial special member' and 'has a non-trivial special member', and use them appropriately. These are not opposites of one another (there might be no special member, or in C++11 there might be a trivial one and a non-trivial one). The CXXRecordDecl predicates continue to produce incorrect results, but do so in fewer cases now, and they document the cases where they might be wrong. No functionality changes are intended here (they will come when the predicates start producing the right answers...). llvm-svn: 168119
* Simplify: replace getContext().getLangOpts() with just getLangOpts().Richard Smith2012-11-011-2/+2
| | | | llvm-svn: 167261
* -fcatch-undefined-behavior: emit calls to the runtime library whenever one ↵Richard Smith2012-10-091-1/+1
| | | | | | of the checks fails. llvm-svn: 165536
* CodeGen: Copy tail padding when we're not dealing with a trivial copy assign ↵Benjamin Kramer2012-09-301-4/+9
| | | | | | | | | | or move assign operator. This fixes a regression from r162254, the optimizer has problems reasoning about the smaller memcpy as it's often not safe to widen a store but making it smaller is. llvm-svn: 164917
* Add basic support for adding !tbaa.struct metadata on llvm.memcpy calls forDan Gohman2012-09-281-1/+7
| | | | | | struct assignment. llvm-svn: 164853
* -fcatch-undefined-behavior: Factor emission of the creation of, and branch to,Richard Smith2012-09-081-1/+1
| | | | | | | | | the trap BB out of the individual checks and into a common function, to prepare for making this code call into a runtime library. Rename the existing EmitCheck to EmitTypeCheck to clarify it and to move it out of the way of the new EmitCheck. llvm-svn: 163451
* Change the representation of builtin functions in the ASTEli Friedman2012-08-311-0/+1
| | | | | | | | | (__builtin_* etc.) so that it isn't possible to take their address. Specifically, introduce a new type to represent a reference to a builtin function, and a new cast kind to convert it to a function pointer in the operand of a call. Fixes PR13195. llvm-svn: 162962
* New -fcatch-undefined-behavior features:Richard Smith2012-08-241-1/+3
| | | | | | | | * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
OpenPOWER on IntegriCloud