summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [opaque pointer types] Trivial changes towards CallInst requiringJames Y Knight2019-02-031-2/+2
| | | | | | explicit function types. llvm-svn: 353009
* [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.Michael Kruse2019-02-011-0/+10
| | | | | | | | | | | | | | | | | This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [ObjCARC] Add an new attribute, objc_externally_retainedErik Pilkington2019-01-041-13/+15
| | | | | | | | | | | | | | | | | | | | This attribute, called "objc_externally_retained", exposes clang's notion of pseudo-__strong variables in ARC. Pseudo-strong variables "borrow" their initializer, meaning that they don't retain/release it, instead assuming that someone else is keeping their value alive. If a function is annotated with this attribute, implicitly strong parameters of that function aren't implicitly retained/released in the function body, and are implicitly const. This is useful to expose for performance reasons, most functions don't need the extra safety of the retain/release, so programmers can opt out as needed. This attribute can also apply to declarations of local variables, with similar effect. Differential revision: https://reviews.llvm.org/D55865 llvm-svn: 350422
* [AST][NFC] Pass the AST context to one of the ctor of DeclRefExpr.Bruno Ricci2018-12-211-2/+2
| | | | | | | | | All of the other constructors already take a reference to the AST context. This avoids calling Decl::getASTContext in most cases. Additionally move the definition of the constructor from Expr.h to Expr.cpp since it is calling DeclRefExpr::computeDependence. NFC. llvm-svn: 349901
* Automatic variable initializationJF Bastien2018-12-181-13/+244
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an option to initialize automatic variables with either a pattern or with zeroes. The default is still that automatic variables are uninitialized. Also add attributes to request uninitialized on a per-variable basis, mainly to disable initialization of large stack arrays when deemed too expensive. This isn't meant to change the semantics of C and C++. Rather, it's meant to be a last-resort when programmers inadvertently have some undefined behavior in their code. This patch aims to make undefined behavior hurt less, which security-minded people will be very happy about. Notably, this means that there's no inadvertent information leak when: - The compiler re-uses stack slots, and a value is used uninitialized. - The compiler re-uses a register, and a value is used uninitialized. - Stack structs / arrays / unions with padding are copied. This patch only addresses stack and register information leaks. There's many more infoleaks that we could address, and much more undefined behavior that could be tamed. Let's keep this patch focused, and I'm happy to address related issues elsewhere. To keep the patch simple, only some `undef` is removed for now, see `replaceUndef`. The padding-related infoleaks are therefore not all gone yet. This will be addressed in a follow-up, mainly because addressing padding-related leaks should be a stand-alone option which is implied by variable initialization. There are three options when it comes to automatic variable initialization: 0. Uninitialized This is C and C++'s default. It's not changing. Depending on code generation, a programmer who runs into undefined behavior by using an uninialized automatic variable may observe any previous value (including program secrets), or any value which the compiler saw fit to materialize on the stack or in a register (this could be to synthesize an immediate, to refer to code or data locations, to generate cookies, etc). 1. Pattern initialization This is the recommended initialization approach. Pattern initialization's goal is to initialize automatic variables with values which will likely transform logic bugs into crashes down the line, are easily recognizable in a crash dump, without being values which programmers can rely on for useful program semantics. At the same time, pattern initialization tries to generate code which will optimize well. You'll find the following details in `patternFor`: - Integers are initialized with repeated 0xAA bytes (infinite scream). - Vectors of integers are also initialized with infinite scream. - Pointers are initialized with infinite scream on 64-bit platforms because it's an unmappable pointer value on architectures I'm aware of. Pointers are initialize to 0x000000AA (small scream) on 32-bit platforms because 32-bit platforms don't consistently offer unmappable pages. When they do it's usually the zero page. As people try this out, I expect that we'll want to allow different platforms to customize this, let's do so later. - Vectors of pointers are initialized the same way pointers are. - Floating point values and vectors are initialized with a negative quiet NaN with repeated 0xFF payload (e.g. 0xffffffff and 0xffffffffffffffff). NaNs are nice (here, anways) because they propagate on arithmetic, making it more likely that entire computations become NaN when a single uninitialized value sneaks in. - Arrays are initialized to their homogeneous elements' initialization value, repeated. Stack-based Variable-Length Arrays (VLAs) are runtime-initialized to the allocated size (no effort is made for negative size, but zero-sized VLAs are untouched even if technically undefined). - Structs are initialized to their heterogeneous element's initialization values. Zero-size structs are initialized as 0xAA since they're allocated a single byte. - Unions are initialized using the initialization for the largest member of the union. Expect the values used for pattern initialization to change over time, as we refine heuristics (both for performance and security). The goal is truly to avoid injecting semantics into undefined behavior, and we should be comfortable changing these values when there's a worthwhile point in doing so. Why so much infinite scream? Repeated byte patterns tend to be easy to synthesize on most architectures, and otherwise memset is usually very efficient. For values which aren't entirely repeated byte patterns, LLVM will often generate code which does memset + a few stores. 2. Zero initialization Zero initialize all values. This has the unfortunate side-effect of providing semantics to otherwise undefined behavior, programs therefore might start to rely on this behavior, and that's sad. However, some programmers believe that pattern initialization is too expensive for them, and data might show that they're right. The only way to make these programmers wrong is to offer zero-initialization as an option, figure out where they are right, and optimize the compiler into submission. Until the compiler provides acceptable performance for all security-minded code, zero initialization is a useful (if blunt) tool. I've been asked for a fourth initialization option: user-provided byte value. This might be useful, and can easily be added later. Why is an out-of band initialization mecanism desired? We could instead use -Wuninitialized! Indeed we could, but then we're forcing the programmer to provide semantics for something which doesn't actually have any (it's uninitialized!). It's then unclear whether `int derp = 0;` lends meaning to `0`, or whether it's just there to shut that warning up. It's also way easier to use a compiler flag than it is to manually and intelligently initialize all values in a program. Why not just rely on static analysis? Because it cannot reason about all dynamic code paths effectively, and it has false positives. It's a great tool, could get even better, but it's simply incapable of catching all uses of uninitialized values. Why not just rely on memory sanitizer? Because it's not universally available, has a 3x performance cost, and shouldn't be deployed in production. Again, it's a great tool, it'll find the dynamic uses of uninitialized variables that your test coverage hits, but it won't find the ones that you encounter in production. What's the performance like? Not too bad! Previous publications [0] have cited 2.7 to 4.5% averages. We've commmitted a few patches over the last few months to address specific regressions, both in code size and performance. In all cases, the optimizations are generally useful, but variable initialization benefits from them a lot more than regular code does. We've got a handful of other optimizations in mind, but the code is in good enough shape and has found enough latent issues that it's a good time to get the change reviewed, checked in, and have others kick the tires. We'll continue reducing overheads as we try this out on diverse codebases. Is it a good idea? Security-minded folks think so, and apparently so does the Microsoft Visual Studio team [1] who say "Between 2017 and mid 2018, this feature would have killed 49 MSRC cases that involved uninitialized struct data leaking across a trust boundary. It would have also mitigated a number of bugs involving uninitialized struct data being used directly.". They seem to use pure zero initialization, and claim to have taken the overheads down to within noise. Don't just trust Microsoft though, here's another relevant person asking for this [2]. It's been proposed for GCC [3] and LLVM [4] before. What are the caveats? A few! - Variables declared in unreachable code, and used later, aren't initialized. This goto, Duff's device, other objectionable uses of switch. This should instead be a hard-error in any serious codebase. - Volatile stack variables are still weird. That's pre-existing, it's really the language's fault and this patch keeps it weird. We should deprecate volatile [5]. - As noted above, padding isn't fully handled yet. I don't think these caveats make the patch untenable because they can be addressed separately. Should this be on by default? Maybe, in some circumstances. It's a conversation we can have when we've tried it out sufficiently, and we're confident that we've eliminated enough of the overheads that most codebases would want to opt-in. Let's keep our precious undefined behavior until that point in time. How do I use it: 1. On the command-line: -ftrivial-auto-var-init=uninitialized (the default) -ftrivial-auto-var-init=pattern -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang 2. Using an attribute: int dont_initialize_me __attribute((uninitialized)); [0]: https://users.elis.ugent.be/~jsartor/researchDocs/OOPSLA2011Zero-submit.pdf [1]: https://twitter.com/JosephBialek/status/1062774315098112001 [2]: https://outflux.net/slides/2018/lss/danger.pdf [3]: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00615.html [4]: https://github.com/AndroidHardeningArchive/platform_external_clang/commit/776a0955ef6686d23a82d2e6a3cbd4a6a882c31c [5]: http://wg21.link/p1152 I've also posted an RFC to cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html <rdar://problem/39131435> Reviewers: pcc, kcc, rsmith Subscribers: JDevlieghere, jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D54604 llvm-svn: 349442
* Move CodeGenOptions from Frontend to BasicRichard Trieu2018-12-111-1/+1
| | | | | | Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
* [OpenMP] Check target architecture supports unified shared memory for ↵Patrick Lyster2018-11-191-1/+1
| | | | | | requires directive. Differential Review: https://reviews.llvm.org/D54493 llvm-svn: 347214
* Fix warning about unused variable [NFC]Mikael Holmen2018-11-151-2/+2
| | | | llvm-svn: 346950
* CGDecl::emitStoresForConstant fix synthesized constant's nameJF Bastien2018-11-151-19/+47
| | | | | | | | | | | | Summary: The name of the synthesized constants for constant initialization was using mangling for statics, which isn't generally correct and (in a yet-uncommitted patch) causes the mangler to assert out because the static ends up trying to mangle function parameters and this makes no sense. Instead, mangle to `"__const." + FunctionName + "." + DeclName`. Reviewers: rjmccall Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D54055 llvm-svn: 346915
* Fix a nondeterminism in the debug info for VLA size expressions.Adrian Prantl2018-11-091-5/+12
| | | | | | | | | | | The artificial variable describing the array size is supposed to be called "__vla_expr", but this was implemented by retrieving the name of the associated alloca, which isn't a reliable source for the name, since nonassert compilers may drop names from LLVM IR. rdar://problem/45924808 llvm-svn: 346542
* Create ConstantExpr classBill Wendling2018-10-311-3/+3
| | | | | | | | | | | | | | | | A ConstantExpr class represents a full expression that's in a context where a constant expression is required. This class reflects the path the evaluator took to reach the expression rather than the syntactic context in which the expression occurs. In the future, the class will be expanded to cache the result of the evaluated expression so that it's not needlessly re-evaluated Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D53475 llvm-svn: 345692
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-10-011-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. This reapplies r343518 after fixing a use-after-free bug in function Sema::ActOnBlockStmtExpr where the BlockScopeInfo was dereferenced after it was popped and deleted. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 343542
* Revert r343518.Akira Hatanaka2018-10-011-10/+9
| | | | | | | | | Bots are still failing. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/24420 http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/12958 llvm-svn: 343531
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-10-011-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. This reapplies r341754, which was reverted in r341757 because it broke a couple of bots. r341754 was calling markEscapingByrefs after the call to PopFunctionScopeInfo, which caused the popped function scope to be cleared out when the following code was compiled, for example: $ cat test.m struct A { id data[10]; }; void foo() { __block A v; ^{ (void)v; }; } This commit calls markEscapingByrefs before calling PopFunctionScopeInfo to prevent that from happening. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 343518
* [OPENMP] Add support for OMP5 requires directive + unified_address clauseKelvin Li2018-09-261-0/+5
| | | | | | | | | Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
* NFC: deduplicate isRepeatedBytePattern from clang to LLVM's isBytewiseValueJF Bastien2018-09-211-101/+13
| | | | | | | | | | | | | Summary: This code was in CGDecl.cpp and really belongs in LLVM. It happened to have isBytewiseValue which served a very similar purpose but wasn't as powerful as clang's version. Remove the clang version, and augment isBytewiseValue to be as powerful so that clang does the same thing it used to. LLVM part of this patch: D51751 Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51752 llvm-svn: 342734
* Revert r341754.Akira Hatanaka2018-09-091-10/+9
| | | | | | | | | The commit broke a couple of bots: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/12347 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/7310 llvm-svn: 341757
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-09-081-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 341754
* [CodeGen] Merge equivalent block copy/helper functions.Akira Hatanaka2018-08-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Clang generates copy and dispose helper functions for each block literal on the stack. Often these functions are equivalent for different blocks. This commit makes changes to merge equivalent copy and dispose helper functions and reduce code size. To enable merging equivalent copy/dispose functions, the captured object infomation is encoded into the helper function name. This allows IRGen to check whether an equivalent helper function has already been emitted and reuse the function instead of generating a new helper function whenever a block is defined. In addition, the helper functions are marked as linkonce_odr to enable merging helper functions that have the same name across translation units and marked as unnamed_addr to enable the linker's deduplication pass to merge functions that have different names but the same content. rdar://problem/42640608 Differential Revision: https://reviews.llvm.org/D50152 llvm-svn: 339438
* [NFC] CGDecl factor out constant emissionJF Bastien2018-08-071-47/+56
| | | | | | The code is cleaner this way, and with some changes I'm playing with it makes sense to split it out so we can reuse it. llvm-svn: 339191
* [CodeGen][ObjC] Make block copy/dispose helper functions exception-safe.Akira Hatanaka2018-07-261-3/+9
| | | | | | | | | | | | | When an exception is thrown in a block copy helper function, captured objects that have previously been copied should be destructed or released. Similarly, captured objects that are yet to be released should be released when an exception is thrown in a dispose helper function. rdar://problem/42410255 Differential Revision: https://reviews.llvm.org/D49718 llvm-svn: 338041
* CodeGen: use non-zero memset when possible for automatic variablesJF Bastien2018-07-251-26/+141
| | | | | | | | | | | | | | | | | Summary: Right now automatic variables are either initialized with bzero followed by a few stores, or memcpy'd from a synthesized global. We end up encountering a fair amount of code where memcpy of non-zero byte patterns would be better than memcpy from a global because it touches less memory and generates a smaller binary. The optimizer could reason about this, but it's not really worth it when clang already knows. This code could definitely be more clever but I'm not sure it's worth it. In particular we could track a histogram of bytes seen and figure out (as we do with bzero) if a memset could be followed by a handful of stores. Similarly, we could tune the heuristics for GlobalSize, but using the same as for bzero seems conservatively OK for now. <rdar://problem/42563091> Reviewers: dexonsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49771 llvm-svn: 337887
* Support lifetime-extension of conditional temporaries.Richard Smith2018-07-231-3/+0
| | | | llvm-svn: 337767
* [NFC] CodeGen: rename memset to bzeroJF Bastien2018-07-201-30/+27
| | | | | | The optimization looks for opportunities to emit bzero, not memset. Rename the functions accordingly (and clang-format the diff) because I want to add a fallback optimization which actually tries to generate memset. bzero is still better and it would confuse the code to merge both. llvm-svn: 337636
* CodeGen: specify alignment + inbounds for automatic variable initializationJF Bastien2018-07-131-7/+10
| | | | | | | | | | Summary: Automatic variable initialization was generating default-aligned stores (which are deprecated) instead of using the known alignment from the alloca. Further, they didn't specify inbounds. Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D49209 llvm-svn: 337041
* CodeGen: block capture shouldn't ICEJF Bastien2018-05-191-13/+26
| | | | | | | | | | When a lambda capture captures a __block in the same statement, the compiler asserts out because isCapturedBy assumes that an Expr can only be a BlockExpr, StmtExpr, or if it's a Stmt then all the statement's children are expressions. That's wrong, we need to visit all sub-statements even if they're not expressions to see if they also capture. Fix this issue by pulling out the isCapturedBy logic to use RecursiveASTVisitor. <rdar://problem/39926584> llvm-svn: 332801
* CodeGen: Fix invalid bitcast for lifetime.start/endYaxun Liu2018-05-171-4/+14
| | | | | | | | | | | | | | lifetime.start/end expects pointer argument in alloca address space. However in C++ a temporary variable is in default address space. This patch changes API CreateMemTemp and CreateTempAlloca to get the original alloca instruction and pass it lifetime.start/end. It only affects targets with non-zero alloca address space. Differential Revision: https://reviews.llvm.org/D45900 llvm-svn: 332593
* Address post-commit review comments after r328731. NFC.Akira Hatanaka2018-05-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | - Define a function (canPassInRegisters) that determines whether a record can be passed in registers based on language rules and target-specific ABI rules. - Set flag RecordDecl::ParamDestroyedInCallee to true in MSVC mode and remove ASTContext::isParamDestroyedInCallee, which is no longer needed. - Use the same type (unsigned) for RecordDecl's bit-field members. For more background, see the following discussions that took place on cfe-commits. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180326/223498.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180402/223688.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180409/224754.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226494.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180507/227647.html llvm-svn: 332397
* CodeGen: Emit string literal in constant address spaceYaxun Liu2018-05-141-6/+5
| | | | | | | | | Some targets have constant address space (e.g. amdgcn). For them string literal should be emitted in constant address space then casted to default address space. Differential Revision: https://reviews.llvm.org/D46643 llvm-svn: 332279
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-1/+1
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [CodeGen] Avoid destructing a callee-destructued struct type in aAkira Hatanaka2018-04-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | function if a function delegates to another function. Fix a bug introduced in r328731, which caused a struct with ObjC __weak fields that was passed to a function to be destructed twice, once in the callee function and once in another function the callee function delegates to. To prevent this, keep track of the callee-destructed structs passed to a function and disable their cleanups at the point of the call to the delegated function. This reapplies r331016, which was reverted in r331019 because it caused an assertion to fail in EmitDelegateCallArg on a windows bot. I made changes to EmitDelegateCallArg so that it doesn't try to deactivate cleanups for structs that have trivial destructors (cleanups for those structs are never pushed to the cleanup stack in EmitParmDecl). rdar://problem/39194693 Differential Revision: https://reviews.llvm.org/D45382 llvm-svn: 331020
* Revert "[CodeGen] Avoid destructing a callee-destructued struct type in a"Akira Hatanaka2018-04-271-2/+0
| | | | | | | | This reverts commit r331016, which broke a windows bot. http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/11727 llvm-svn: 331019
* [CodeGen] Avoid destructing a callee-destructued struct type in aAkira Hatanaka2018-04-271-0/+2
| | | | | | | | | | | | | | | | | function if a function delegates to another function. Fix a bug introduced in r328731, which caused a struct with ObjC __weak fields that was passed to a function to be destructed twice, once in the callee function and once in another function the callee function delegates to. To prevent this, keep track of the callee-destructed structs passed to a function and disable their cleanups at the point of the call to the delegated function. rdar://problem/39194693 Differential Revision: https://reviews.llvm.org/D45382 llvm-svn: 331016
* Revert rC330794 and some dependent tiny bug fixes Faisal Vali2018-04-261-1/+0
| | | | | | | | | | | | | | See Richard's humbling feedback here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226482.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226486.html Wish I'd had the patience to solicit the feedback prior to committing :) Sorry for the noise guys. Thank you Richard for being the steward that clang deserves! llvm-svn: 330888
* [c++2a] [concepts] Add rudimentary parsing support for template concept ↵Faisal Vali2018-04-251-0/+1
| | | | | | | | | | | | | | declarations This patch is a tweak of changyu's patch: https://reviews.llvm.org/D40381. It differs in that the recognition of the 'concept' token is moved into the machinery that recognizes declaration-specifiers - this allows us to leverage the attribute handling machinery more seamlessly. See the test file to get a sense of the basic parsing that this patch supports. There is much more work to be done before concepts are usable... Thanks Changyu! llvm-svn: 330794
* PR36992: do not store beyond the dsize of a class object unless we knowRichard Smith2018-04-051-7/+13
| | | | | | | | | | | | | | the tail padding is not reused. We track on the AggValueSlot (and through a couple of other initialization actions) whether we're dealing with an object that might share its tail padding with some other object, so that we can avoid emitting stores into the tail padding if that's the case. We still widen stores into tail padding when we can do so. Differential Revision: https://reviews.llvm.org/D45306 llvm-svn: 329342
* [CUDA] Let device-side shared variables be initialized with undefYaxun Liu2018-04-021-4/+6
| | | | | | | | | | | CUDA shared variable should be initialized with undef. Patch by Greg Rodgers. Revised and lit test added by Yaxun Liu. Differential Revision: https://reviews.llvm.org/D44985 llvm-svn: 328994
* Generalize NRVO to cover C structs.Akira Hatanaka2018-03-291-12/+46
| | | | | | | | | | | This commit generalizes NRVO to cover C structs (both trivial and non-trivial structs). rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D44968 llvm-svn: 328809
* [OPENMP] Codegen for `omp declare target` construct.Alexey Bataev2018-03-151-1/+4
| | | | | | | | Added initial codegen for device side of declarations inside `omp declare target` construct + codegen for implicit `declare target` functions, which are used in the target regions. llvm-svn: 327636
* Recommit r326946 after reducing CallArgList memory footprintYaxun Liu2018-03-151-0/+16
| | | | llvm-svn: 327634
* [OpenMP] Add OpenMP data sharing infrastructure using global memoryGheorghe-Teodor Bercea2018-03-141-6/+23
| | | | | | | | | | | | | | | | | Summary: This patch handles the Clang code generation phase for the OpenMP data sharing infrastructure. TODO: add a more detailed description. Reviewers: ABataev, carlo.bertolli, caomhin, hfinkel, Hahnfeld Reviewed By: ABataev Subscribers: jholewinski, guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D43660 llvm-svn: 327513
* Revert r326946. It caused stack overflows by significantly increasing the ↵Richard Smith2018-03-101-16/+0
| | | | | | size of a CallArgList. llvm-svn: 327195
* CodeGen: Fix address space of indirect function argumentYaxun Liu2018-03-071-0/+16
| | | | | | | | | | | | | | | | | | | | | The indirect function argument is in alloca address space in LLVM IR. However, during Clang codegen for C++, the address space of indirect function argument should match its address space in the source code, i.e., default addr space, even for indirect argument. This is because destructor of the indirect argument may be called in the caller function, and address of the indirect argument may be taken, in either case the indirect function argument is expected to be in default addr space, not the alloca address space. Therefore, the indirect function argument should be mapped to the temp var casted to default address space. The caller will cast it to alloca addr space when passing it to the callee. In the callee, the argument is also casted to the default address space and used. CallArg is refactored to facilitate this fix. Differential Revision: https://reviews.llvm.org/D34367 llvm-svn: 326946
* Start setting dllimport/dllexport in setGVProperties.Rafael Espindola2018-03-011-7/+0
| | | | | | | | | | This is the next step in setting dso_local for COFF. The patches changes setGVProperties to first set dllimport/dllexport and changes a few cases that were setting dllimport/dllexport manually. With this a few more GVs are marked dso_local. llvm-svn: 326397
* [ObjC] Allow declaring __strong pointer fields in structs in Objective-CAkira Hatanaka2018-02-281-3/+25
| | | | | | | | | | | | | | | | | | | | | ARC mode. Declaring __strong pointer fields in structs was not allowed in Objective-C ARC until now because that would make the struct non-trivial to default-initialize, copy/move, and destroy, which is not something C was designed to do. This patch lifts that restriction. Special functions for non-trivial C structs are synthesized that are needed to default-initialize, copy/move, and destroy the structs and manage the ownership of the objects the __strong pointer fields point to. Non-trivial structs passed to functions are destructed in the callee function. rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D41228 llvm-svn: 326307
* Bring r325915 back.Rafael Espindola2018-02-231-1/+2
| | | | | | | | | | | | | | | The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
* Revert "Start setting dso_local for COFF."Rafael Espindola2018-02-231-2/+1
| | | | | | | | This reverts commit r325915. It will take some time to fix the failures on a windows host. llvm-svn: 325929
* Start setting dso_local for COFF.Rafael Espindola2018-02-231-1/+2
| | | | | | | | | With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325915
* CodeGen: handle blocks correctly when inalloca'edSaleem Abdulrasool2018-02-211-2/+5
| | | | | | | | | | When using blocks with C++ on Windows x86, it is possible to have the block literal be pushed into the inalloca'ed parameters. Teach IRGen to handle the case properly by extracting the block literal from the inalloca parameter. This fixes the use of blocks with C++ on Windows x86. llvm-svn: 325724
OpenPOWER on IntegriCloud