summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CodeGenFunction.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Expose -mllvm -accurate-sample-profile to clang.Dehao Chen2017-08-241-0/+4
| | | | | | | | | | | | | | Summary: With accurate sample profile, we can do more aggressive size optimization. For some size-critical application, this can reduce the text size by 20% Reviewers: davidxl, rsmith Reviewed By: davidxl, rsmith Subscribers: mehdi_amini, eraman, sanjoy, cfe-commits Differential Revision: https://reviews.llvm.org/D37091 llvm-svn: 311707
* [ubsan] PR34266: When sanitizing the 'this' value for a member function that ↵Richard Smith2017-08-241-2/+14
| | | | | | | | | | | | | happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any). Do not sanitize the 'this' pointer of a member call operator for a lambda with no capture-default, since that call operator can legitimately be called with a null this pointer from the static invoker function. Any actual call with a null this pointer should still be caught in the caller (if it is being sanitized). This reinstates r311589 (reverted in r311680) with the above fix. llvm-svn: 311695
* Revert "[ubsan] PR34266: When sanitizing the 'this' value for a member ↵Adrian Prantl2017-08-241-2/+2
| | | | | | | | | function that happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any)." This reverts commit r311589 because of bot breakage. http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan_check/4115/consoleFull#15752874848254eaf0-7326-4999-85b0-388101f2d404. llvm-svn: 311680
* [ubsan] PR34266: When sanitizing the 'this' value for a member function that ↵Richard Smith2017-08-231-2/+2
| | | | | | happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any). llvm-svn: 311589
* Clean up some lambda conversion operator code, NFCReid Kleckner2017-08-041-8/+3
| | | | | | | | | | | | | | We don't need special handling in CodeGenFunction::GenerateCode for lambda block pointer conversion operators anymore. The conversion operator emission code immediately calls back to the generic EmitFunctionBody. Rename EmitLambdaStaticInvokeFunction to EmitLambdaStaticInvokeBody for better consistency with the other Emit*Body methods. I'm preparing to do something about PR28299, which touches this code. llvm-svn: 310145
* Reland "CFI: blacklist STL allocate() from unrelated-casts"Vlad Tsyrklevich2017-08-041-0/+28
| | | | | | | | Reland r310097 with a fix for a debug assertion in NamedDecl.getName() Differential Revision: https://reviews.llvm.org/D36294 llvm-svn: 310132
* Revert "Reland "CFI: blacklist STL allocate() from unrelated-casts""Vlad Tsyrklevich2017-08-041-27/+0
| | | | | | This reverts commit r310105. llvm-svn: 310121
* Reland "CFI: blacklist STL allocate() from unrelated-casts"Vlad Tsyrklevich2017-08-041-0/+27
| | | | | | | | Reland r310097 with a unit test fix for MS ABI build bots. Differential Revision: https://reviews.llvm.org/D36294 llvm-svn: 310105
* Revert "CFI: blacklist STL allocate() from unrelated-casts"Vlad Tsyrklevich2017-08-041-27/+0
| | | | | | This reverts commit r310097. llvm-svn: 310099
* CFI: blacklist STL allocate() from unrelated-castsVlad Tsyrklevich2017-08-041-0/+27
| | | | | | | | | | | | | | | | | | | | | | Summary: Previously, STL allocators were blacklisted in compiler_rt's cfi_blacklist.txt because they mandated a cast from void* to T* before object initialization completed. This change moves that logic into the front end because C++ name mangling supports a substitution compression mechanism for symbols that makes it difficult to blacklist the mangled symbol for allocate() using a regular expression. Motivated by crbug.com/751385. Reviewers: pcc, kcc Reviewed By: pcc Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D36294 llvm-svn: 310097
* [OpenCL] Fix access qualifiers metadata for kernel arguments with typedefAlexey Sotkin2017-07-261-1/+4
| | | | | | | | Subscribers: cfe-commits, yaxunl, Anastasia Differential Revision: https://reviews.llvm.org/D35420 llvm-svn: 309155
* [ubsan] Improve diagnostics for return value checks (clang)Vedant Kumar2017-06-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes ubsan's nonnull return value diagnostics more precise, which makes the diagnostics more useful when there are multiple return statements in a function. Example: 1 |__attribute__((returns_nonnull)) char *foo() { 2 | if (...) { 3 | return expr_which_might_evaluate_to_null(); 4 | } else { 5 | return another_expr_which_might_evaluate_to_null(); 6 | } 7 |} // <- The current diagnostic always points here! runtime error: Null returned from Line 7, Column 2! With this patch, the diagnostic would point to either Line 3, Column 5 or Line 5, Column 5. This is done by emitting source location metadata for each return statement in a sanitized function. The runtime is passed a pointer to the appropriate metadata so that it can prepare and deduplicate reports. Compiler-rt patch (with more tests): https://reviews.llvm.org/D34298 Differential Revision: https://reviews.llvm.org/D34299 llvm-svn: 306163
* [Clang] Handle interaction of -pg and no_instrument_function attribute.Manoj Gupta2017-06-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: Disable generation of counting-function attribute if no_instrument_function attribute is present in function. Interaction between -pg and no_instrument_function is the desired behavior and matches gcc as well. This is required for fixing a crash in Linux kernel when function tracing is enabled. Fixes PR33515. Reviewers: hfinkel, rengolin, srhines, hans Reviewed By: hfinkel Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34357 llvm-svn: 305728
* [DebugInfo] Add kind of ImplicitParamDecl for emission of FlagObjectPointer.Alexey Bataev2017-06-091-3/+2
| | | | | | | | | | | | | | | | | Summary: If the first parameter of the function is the ImplicitParamDecl, codegen automatically marks it as an implicit argument with `this` or `self` pointer. Added internal kind of the ImplicitParamDecl to separate 'this', 'self', 'vtt' and other implicit parameters from other kind of parameters. Reviewers: rjmccall, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33735 llvm-svn: 305075
* [CGDebugInfo] Finalize SubPrograms when we're done with themKeno Fischer2017-06-011-1/+1
| | | | | | | | | | | | | | | | | | `GenerateVarArgsThunk` in `CGVTables` clones a function before the frontend is done emitting the compilation unit. Because of the way that DIBuilder works, this means that the attached subprogram had incomplete (temporary) metadata. Cloning such metadata is semantically disallowed, but happened to work anyway due to bugs in the cloning logic. rL304226 attempted to fix up that logic, but in the process exposed the incorrect API use here and had to be reverted. To be able to fix this, I added a new method to DIBuilder in rL304467, to allow finalizing a subprogram independently of the entire compilation unit. Use that here, in preparation of re-applying rL304226. Reviewers: aprantl, dblaikie Differential Revision: https://reviews.llvm.org/D33705 llvm-svn: 304470
* [CodeGen] Propagate LValueBaseInfo instead of AlignmentSourceKrzysztof Parzyszek2017-05-181-11/+13
| | | | | | | | | | | | | The functions creating LValues propagated information about alignment source. Extend the propagated data to also include information about possible unrestricted aliasing. A new class LValueBaseInfo will contain both AlignmentSource and MayAlias info. This patch should not introduce any functional changes. Differential Revision: https://reviews.llvm.org/D33284 llvm-svn: 303358
* [OpenCL] Add intel_reqd_sub_group_size attribute supportXiuli Pan2017-05-041-12/+20
| | | | | | | | | | | | | | | | Summary: Add intel_reqd_sub_group_size attribute support as intel extension cl_intel_required_subgroup_size from https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_required_subgroup_size.txt Reviewers: Anastasia, bader, hfinkel, pxli168 Reviewed By: Anastasia, bader, pxli168 Subscribers: cfe-commits, yaxunl Differential Revision: https://reviews.llvm.org/D30805 llvm-svn: 302125
* [ubsan] Reduce alignment checking of C++ object pointersVedant Kumar2017-04-141-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches ubsan to insert an alignment check for the 'this' pointer at the start of each method/lambda. This allows clang to emit significantly fewer alignment checks overall, because if 'this' is aligned, so are its fields. This is essentially the same thing r295515 does, but for the alignment check instead of the null check. One difference is that we keep the alignment checks on member expressions where the base is a DeclRefExpr. There's an opportunity to diagnose unaligned accesses in this situation (as pointed out by Eli, see PR32630). Testing: check-clang, check-ubsan, and a stage2 ubsan build. Along with the patch from D30285, this roughly halves the amount of alignment checks we emit when compiling X86FastISel.cpp. Here are the numbers from patched/unpatched clangs based on r298160. ------------------------------------------ | Setup | # of alignment checks | ------------------------------------------ | unpatched, -O0 | 24326 | | patched, -O0 | 12717 | (-47.7%) ------------------------------------------ Differential Revision: https://reviews.llvm.org/D30283 llvm-svn: 300370
* [OpenCL] Do not generate "kernel_arg_type_qual" metadata for non-pointer argsEgor Churaev2017-03-311-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: "kernel_arg_type_qual" metadata should contain const/volatile/restrict tags only for pointer types to match the corresponding requirement of the OpenCL specification. OpenCL 2.0 spec 5.9.3 Kernel Object Queries: CL_KERNEL_ARG_TYPE_VOLATILE is returned if the argument is a pointer and the referenced type is declared with the volatile qualifier. [...] Similarly, CL_KERNEL_ARG_TYPE_CONST is returned if the argument is a pointer and the referenced type is declared with the restrict or const qualifier. [...] CL_KERNEL_ARG_TYPE_RESTRICT will be returned if the pointer type is marked restrict. Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: bader, yaxunl Differential Revision: https://reviews.llvm.org/D31321 llvm-svn: 299192
* [msan] Turn off lifetime markers even when use after scope checking is on.Benjamin Kramer2017-03-311-4/+4
| | | | | | | | | Since r299174 use after scope checking is on by default. Even though msan doesn't check for use after scope it gets confused by the lifetime markers emitted for it, making unit tests fail. This is covered by ninja check-msan. llvm-svn: 299191
* [XRay] Add -fxray-{always,never}-instrument= flags to clangDean Michael Berris2017-03-301-3/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: The -fxray-always-instrument= and -fxray-never-instrument= flags take filenames that are used to imbue the XRay instrumentation attributes using a whitelist mechanism (similar to the sanitizer special cases list). We use the same syntax and semantics as the sanitizer blacklists files in the implementation. As implemented, we respect the attributes that are already defined in the source file (i.e. those that have the [[clang::xray_{always,never}_instrument]] attributes) before applying the always/never instrument lists. Reviewers: rsmith, chandlerc Subscribers: jfb, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30388 llvm-svn: 299041
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach UBSan to detect when a value with the _Nonnull type annotation assumes a null value. Call expressions, initializers, assignments, and return statements are all checked. Because _Nonnull does not affect IRGen, the new checks are disabled by default. The new driver flags are: -fsanitize=nullability-arg (_Nonnull violation in call) -fsanitize=nullability-assign (_Nonnull violation in assignment) -fsanitize=nullability-return (_Nonnull violation in return stmt) -fsanitize=nullability (all of the above) This patch builds on top of UBSan's existing support for detecting violations of the nonnull attributes ('nonnull' and 'returns_nonnull'), and relies on the compiler-rt support for those checks. Eventually we will need to update the diagnostic messages in compiler-rt (there are FIXME's for this, which will be addressed in a follow-up). One point of note is that the nullability-return check is only allowed to kick in if all arguments to the function satisfy their nullability preconditions. This makes it necessary to emit some null checks in the function body itself. Testing: check-clang and check-ubsan. I also built some Apple ObjC frameworks with an asserts-enabled compiler, and verified that we get valid reports. Differential Revision: https://reviews.llvm.org/D30762 llvm-svn: 297700
* Honor __unaligned in codegen for declarations and expressionsRoger Ferrer Ibanez2017-03-081-0/+2
| | | | | | | | | | | This patch honors the unaligned type qualifier (currently available through he keyword __unaligned and -fms-extensions) in CodeGen. In the current form the patch affects declarations and expressions. It does not affect fields of classes. Differential Revision: https://reviews.llvm.org/D30166 llvm-svn: 297276
* [XRay] [clang] Allow logging the first argument of a function call.Dean Michael Berris2017-03-061-0/+4
| | | | | | | | | | | | | | | | Summary: Functions with the "xray_log_args" attribute will tell LLVM to emit a special XRay sled for compiler-rt to copy any call arguments to your logging handler. Reviewers: dberris Reviewed By: dberris Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D29704 llvm-svn: 296999
* Retry^2: [ubsan] Reduce null checking of C++ object pointers (PR27581)Vedant Kumar2017-02-171-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda. Previously, given a load of a member variable from an instance method ('this->x'), ubsan would insert a null check for 'this', and another null check for '&this->x', before allowing the load to occur. Similarly, given a call to a method from another method bound to the same instance ('this->foo()'), ubsan would a redundant null check for 'this'. There is also a redundant null check in the case where the object pointer is a reference ('Ref.foo()'). This patch teaches ubsan to remove the redundant null checks identified above. Testing: check-clang, check-ubsan, and a stage2 ubsan build. I also compiled X86FastISel.cpp with -fsanitize=null using patched/unpatched clangs based on r293572. Here are the number of null checks emitted: ------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 21767 | | patched, -O0 | 10758 | ------------------------------------- Changes since the initial commit: - Don't introduce any unintentional object-size or alignment checks. - Don't rely on IRGen of C labels in the test. Differential Revision: https://reviews.llvm.org/D29530 llvm-svn: 295515
* Revert "Retry: [ubsan] Reduce null checking of C++ object pointers (PR27581)"Vedant Kumar2017-02-171-5/+0
| | | | | | | | This reverts commit r295401. It breaks the ubsan self-host. It inserts object size checks once per C++ method which fire when the structure is empty. llvm-svn: 295494
* Retry: [ubsan] Reduce null checking of C++ object pointers (PR27581)Vedant Kumar2017-02-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda. Previously, given a load of a member variable from an instance method ('this->x'), ubsan would insert a null check for 'this', and another null check for '&this->x', before allowing the load to occur. Similarly, given a call to a method from another method bound to the same instance ('this->foo()'), ubsan would a redundant null check for 'this'. There is also a redundant null check in the case where the object pointer is a reference ('Ref.foo()'). This patch teaches ubsan to remove the redundant null checks identified above. Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp with -fsanitize=null using patched/unpatched clangs based on r293572. Here are the number of null checks emitted: ------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 21767 | | patched, -O0 | 10758 | ------------------------------------- Changes since the initial commit: don't rely on IRGen of C labels in the test. Differential Revision: https://reviews.llvm.org/D29530 llvm-svn: 295401
* Revert "[ubsan] Reduce null checking of C++ object pointers (PR27581)"Vedant Kumar2017-02-171-5/+0
| | | | | | | | | | This reverts commit r295391. It breaks this bot: http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/1898 I need to not rely on labels in the IR test. llvm-svn: 295396
* [ubsan] Reduce null checking of C++ object pointers (PR27581)Vedant Kumar2017-02-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches ubsan to insert exactly one null check for the 'this' pointer per method/lambda. Previously, given a load of a member variable from an instance method ('this->x'), ubsan would insert a null check for 'this', and another null check for '&this->x', before allowing the load to occur. Similarly, given a call to a method from another method bound to the same instance ('this->foo()'), ubsan would a redundant null check for 'this'. There is also a redundant null check in the case where the object pointer is a reference ('Ref.foo()'). This patch teaches ubsan to remove the redundant null checks identified above. Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp with -fsanitize=null using patched/unpatched clangs based on r293572. Here are the number of null checks emitted: ------------------------------------- | Setup | # of null checks | ------------------------------------- | unpatched, -O0 | 21767 | | patched, -O0 | 10758 | ------------------------------------- Differential Revision: https://reviews.llvm.org/D29530 llvm-svn: 295391
* [MS] Fix C++ destructor thunk line info for a declarationReid Kleckner2017-02-081-1/+6
| | | | | | | | | | Sometimes the MS ABI needs to emit thunks for declarations that don't have bodies. Destructor thunks make calls to inlinable functions, so they need line info or LLVM will complain. Fixes PR31893 llvm-svn: 294465
* [X86] Teach Clang about -mfentry flagNirav Dave2017-01-311-2/+6
| | | | | | | | | | | | Replace mcount calls with calls to fentry. Reviewers: hfinkel, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28001 llvm-svn: 293649
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-261-1/+3
| | | | | | | | | | | | | | | This change adds a new type node, DeducedTemplateSpecializationType, to represent a type template name that has been used as a type. This is modeled around AutoType, and shares a common base class for representing a deduced placeholder type. We allow deduced class template types in a few more places than the standard does: in conditions and for-range-declarators, and in new-type-ids. This is consistent with GCC and with discussion on the core reflector. This patch does not yet support deduced class template types being named in typename specifiers. llvm-svn: 293207
* [OPENMP] Fix for PR31643: Clang crashes when compiling code on WindowsAlexey Bataev2017-01-201-2/+1
| | | | | | | | | | with SEH and openmp In some cituations (during codegen for Windows SEH constructs) CodeGenFunction instance may have CurFn equal to nullptr. OpenMP related code does not expect such situation during cleanup. llvm-svn: 292590
* [tsan] Do not report errors in __destroy_helper_block_Anna Zaks2017-01-131-3/+11
| | | | | | | | | | There is a synchronization point between the reference count of a block dropping to zero and it's destruction, which TSan does not observe. Do not report errors in the compiler-emitted block destroy method and everything called from it. This is similar to https://reviews.llvm.org/D25857 Differential Revision: https://reviews.llvm.org/D28387 llvm-svn: 291868
* Add a cc1 option to force disabling lifetime-markers emission from clangMehdi Amini2017-01-061-0/+3
| | | | | | | | Summary: This intended as a debugging/development flag only. Differential Revision: https://reviews.llvm.org/D28385 llvm-svn: 291300
* Add -f[no-]strict-return flag that can be used to avoid undefined behaviourAlex Lorenz2017-01-041-4/+23
| | | | | | | | | | | | | | | | | | | | | | | in non-void functions that fall off at the end without returning a value when compiling C++. Clang uses the new compiler flag to determine when it should treat control flow paths that fall off the end of a non-void function as unreachable. If -fno-strict-return is on, the code generator emits the ureachable and trap IR only when the function returns either a record type with a non-trivial destructor or another non-trivially copyable type. The primary goal of this flag is to avoid treating falling off the end of a non-void function as undefined behaviour. The burden of undefined behaviour is placed on the caller instead: if the caller ignores the returned value then the undefined behaviour is avoided. This kind of behaviour is useful in several cases, e.g. when compiling C code in C++ mode. rdar://13102603 Differential Revision: https://reviews.llvm.org/D27163 llvm-svn: 290960
* Cleanup the handling of noinline function attributes, -fno-inline,Chandler Carruth2016-12-231-19/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
* [clang] Version support for UBSan handlersFilipe Cabecinhas2016-12-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | This adds a way for us to version any UBSan handler by itself. The patch overrides D21289 for a better implementation (we're able to rev up a single handler). After this, then we can land a slight modification of D19667+D19668. We probably don't want to keep all the versions in compiler-rt (maybe we want to deprecate on one release and remove the old handler on the next one?), but with this patch we will loudly fail to compile when mixing incompatible handler calls, instead of silently compiling and then providing bad error messages. Reviewers: kcc, samsonov, rsmith, vsk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D21695 llvm-svn: 289444
* [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MDPekka Jaaskelainen2016-11-141-3/+19
| | | | | | | | | | | | | | | It doesn't make sense to use the target's address space ids in this context as this is metadata that should be referring to the "logical" OpenCL address spaces. For flat AS machines like all "CPUs" in general, the logical AS info gets lost as there's only one address space (0). This commit changes the logic such that we always use the SPIR address space ids for the argument metadata. It thus allows implementing the clGetKernelArgInfo() and the other detection needs. https://reviews.llvm.org/D26157 llvm-svn: 286819
* [tsan][clang] Introduce a function attribute to disable TSan checking at run ↵Anna Zaks2016-11-111-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | time This introduces a function annotation that disables TSan checking for the function at run time. The benefit over attribute((no_sanitize("thread"))) is that the accesses within the callees will also be suppressed. The motivation for this attribute is a guarantee given by the objective C language that the calls to the reference count decrement and object deallocation will be synchronized. To model this properly, we would need to intercept all ref count decrement calls (which are very common in ObjC due to use of ARC) and also every single message send. Instead, we propose to just ignore all accesses made from within dealloc at run time. The main downside is that this still does not introduce any synchronization, which means we might still report false positives if the code that relies on this synchronization is not executed from within dealloc. However, we have not seen this in practice so far and think these cases will be very rare. (This problem is similar in nature to https://reviews.llvm.org/D21609; unfortunately, the same solution does not apply here.) Differential Revision: https://reviews.llvm.org/D25857 llvm-svn: 286672
* Add the loop end location to the loop metadata. This additional informationAmara Emerson2016-11-101-0/+7
| | | | | | | | | | | | can be used to improve the locations when generating remarks for loops. Depends on the companion LLVM change r286227. Patch by Florian Hahn. Differential Revision: https://reviews.llvm.org/D25764 llvm-svn: 286456
* [CodeGen] Don't emit lifetime intrinsics for some local variablesVitaly Buka2016-10-261-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Current generation of lifetime intrinsics does not handle cases like: ``` { char x; l1: bar(&x, 1); } goto l1; ``` We will get code like this: ``` %x = alloca i8, align 1 call void @llvm.lifetime.start(i64 1, i8* nonnull %x) br label %l1 l1: %call = call i32 @bar(i8* nonnull %x, i32 1) call void @llvm.lifetime.end(i64 1, i8* nonnull %x) br label %l1 ``` So the second time bar was called for x which is marked as dead. Lifetime markers here are misleading so it's better to remove them at all. This type of bypasses are rare, e.g. code detects just 8 functions building clang (2329 targets). PR28267 Reviewers: eugenis Subscribers: beanz, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D24693 llvm-svn: 285176
* [CodeGen] Move shouldEmitLifetimeMarkers into more convenient placeVitaly Buka2016-10-261-10/+27
| | | | | | | | | | | | Summary: D24693 will need access to it from other places Reviewers: eugenis Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24695 llvm-svn: 285158
* Fix a couple of wrong-code bugs in switch-on-constant optimization:Richard Smith2016-09-161-0/+23
| | | | | | | | | | | | * recurse through intermediate LabelStmts and AttributedStmts when checking whether a statement inside a switch declares a variable * if the end of a compound statement is reachable from the chosen case label, and the compound statement contains a variable declaration, it's not valid to just emit the contents of the compound statement -- we must emit the statement itself or we lose the scope (and thus end lifetimes at the wrong point) llvm-svn: 281797
* ObjectiveC generics: Add ObjCTypeParamType in the type system.Manman Ren2016-09-131-0/+1
| | | | | | | | | | | | | | | | | We also need to add ObjCTypeParamTypeLoc. ObjCTypeParamType supports the representation of "T <protocol>" where T is a type parameter. Before this, we use TypedefType to represent the type parameter for ObjC. ObjCTypeParamType has "ObjCTypeParamDecl *OTPDecl" and it extends from ObjCProtocolQualifiers. It is a non-canonical type and is canonicalized to the underlying type with the protocol qualifiers. rdar://24619481 rdar://25060179 Differential Revision: http://reviews.llvm.org/D23079 llvm-svn: 281355
* Update Clang for D20147 ("DebugInfo: New metadata representation for global ↵Peter Collingbourne2016-09-131-2/+2
| | | | | | | | variables.") Differential Revision: http://reviews.llvm.org/D20415 llvm-svn: 281285
* [OpenCL] Remove access qualifiers on images in arg info metadata.Alexey Bader2016-09-061-2/+31
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Remove access qualifiers on images in arg info metadata: * kernel_arg_type * kernel_arg_base_type Image access qualifiers are inseparable from type in clang implementation, but OpenCL spec provides a special query to get access qualifier via clGetKernelArgInfo with CL_KERNEL_ARG_ACCESS_QUALIFIER. Besides that OpenCL conformance test_api get_kernel_arg_info expects image types without access qualifier. Patch by Evgeniy Tyurin. Reviewers: bader, yaxunl, Anastasia Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23915 llvm-svn: 280699
* [Frontend] Fix mcount inlining bugHonggyu Kim2016-09-011-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Since some profiling tools, such as gprof, ftrace, and uftrace, use -pg option to generate a mcount function call at the entry of each function. Function invocation can be detected by this hook function. But mcount insertion is done before function inlining phase in clang, sometime a function that already has a mcount call can be inlined in the middle of another function. This patch adds an attribute "counting-function" to each function rather than emitting the mcount call directly in frontend so that this attribute can be processed in backend. Then the mcount calls can be properly inserted in backend after all the other optimizations are completed. Link: https://llvm.org/bugs/show_bug.cgi?id=28660 Reviewers: hans, rjmccall, hfinkel, rengolin, compnerd Subscribers: shenhan, cfe-commits Differential Revision: https://reviews.llvm.org/D22666 llvm-svn: 280355
* Remove whitespace to test commit accessHonggyu Kim2016-09-011-1/+1
| | | | llvm-svn: 280337
* Add XRay flags to Clang. We implement two flags to control the XRay behaviour:Aaron Ballman2016-07-131-0/+20
| | | | | | | | | | | -fxray-instrument: enables XRay annotation of IR -fxray-instruction-threshold: configures the threshold for function size (looking at IR instructions), and allow LLVM to decide whether to add the nop sleds later on in the process. Also implements the related xray_always_instrument and xray_never_instrument function attributes. Patch by Dean Michael Berris. llvm-svn: 275330
OpenPOWER on IntegriCloud