#
880d8605 |
| 20-Jan-2017 |
Alexey Bataev <a.bataev@hotmail.com> |
[OPENMP] Fix for PR31643: Clang crashes when compiling code on Windows with SEH and openmp
In some cituations (during codegen for Windows SEH constructs) CodeGenFunction instance may have CurFn equa
[OPENMP] Fix for PR31643: Clang crashes when compiling code on Windows 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
show more ...
|
Revision tags: llvmorg-4.0.0-rc1 |
|
#
e43b4fc0 |
| 13-Jan-2017 |
Anna Zaks <ganna@apple.com> |
[tsan] Do not report errors in __destroy_helper_block_
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
[tsan] Do not report errors in __destroy_helper_block_
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
show more ...
|
#
7f873070 |
| 06-Jan-2017 |
Mehdi Amini <mehdi.amini@apple.com> |
Add a cc1 option to force disabling lifetime-markers emission from clang
Summary: This intended as a debugging/development flag only.
Differential Revision: https://reviews.llvm.org/D28385
llvm-sv
Add a cc1 option to force disabling lifetime-markers emission from clang
Summary: This intended as a debugging/development flag only.
Differential Revision: https://reviews.llvm.org/D28385
llvm-svn: 291300
show more ...
|
#
c1608f7f |
| 04-Jan-2017 |
Alex Lorenz <arphaman@gmail.com> |
Add -f[no-]strict-return flag that can be used to avoid undefined behaviour in non-void functions that fall off at the end without returning a value when compiling C++.
Clang uses the new compiler f
Add -f[no-]strict-return flag that can be used to avoid undefined behaviour 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
show more ...
|
#
fcd33149 |
| 23-Dec-2016 |
Chandler Carruth <chandlerc@gmail.com> |
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone.
These were really, really tangled together: - We used the noinline LLVM attribute for -fno
Cleanup the handling of noinline function attributes, -fno-inline, -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
show more ...
|
#
322ecd90 |
| 12-Dec-2016 |
Filipe Cabecinhas <me@filcab.net> |
[clang] Version support for UBSan handlers
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 handle
[clang] Version support for UBSan handlers
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
show more ...
|
Revision tags: llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
#
2a1cc587 |
| 14-Nov-2016 |
Pekka Jaaskelainen <pekka.jaaskelainen@tut.fi> |
[OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD
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 "
[OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD
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
show more ...
|
#
bcd35a8e |
| 11-Nov-2016 |
Anna Zaks <ganna@apple.com> |
[tsan][clang] Introduce a function attribute to disable TSan checking at run time
This introduces a function annotation that disables TSan checking for the function at run time. The benefit over att
[tsan][clang] Introduce a function attribute to disable TSan checking at run 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
show more ...
|
#
652795db |
| 10-Nov-2016 |
Amara Emerson <amara.emerson@arm.com> |
Add the loop end location to the loop metadata. This additional information can be used to improve the locations when generating remarks for loops.
Depends on the companion LLVM change r286227.
Pat
Add the loop end location to the loop metadata. This additional information 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
show more ...
|
#
64c80b4e |
| 26-Oct-2016 |
Vitaly Buka <vitalybuka@google.com> |
[CodeGen] Don't emit lifetime intrinsics for some local variables
Summary: Current generation of lifetime intrinsics does not handle cases like:
``` { char x; l1: bar(&x, 1); } goto
[CodeGen] Don't emit lifetime intrinsics for some local variables
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
show more ...
|
#
1c94332e |
| 26-Oct-2016 |
Vitaly Buka <vitalybuka@google.com> |
[CodeGen] Move shouldEmitLifetimeMarkers into more convenient place
Summary: D24693 will need access to it from other places
Reviewers: eugenis
Subscribers: cfe-commits
Differential Revision: htt
[CodeGen] Move shouldEmitLifetimeMarkers into more convenient place
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
show more ...
|
#
d8e3ac31 |
| 16-Sep-2016 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Fix a couple of wrong-code bugs in switch-on-constant optimization:
* recurse through intermediate LabelStmts and AttributedStmts when checking whether a statement inside a switch declares a var
Fix a couple of wrong-code bugs in switch-on-constant optimization:
* 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
show more ...
|
#
e6be26c8 |
| 13-Sep-2016 |
Manman Ren <manman.ren@gmail.com> |
ObjectiveC generics: Add ObjCTypeParamType in the type system.
We also need to add ObjCTypeParamTypeLoc. ObjCTypeParamType supports the representation of "T <protocol>" where T is a type parameter.
ObjectiveC generics: Add ObjCTypeParamType in the type system.
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
show more ...
|
#
eeb56abe |
| 13-Sep-2016 |
Peter Collingbourne <peter@pcc.me.uk> |
Update Clang for D20147 ("DebugInfo: New metadata representation for global variables.")
Differential Revision: http://reviews.llvm.org/D20415
llvm-svn: 281285
|
#
3e0b817b |
| 06-Sep-2016 |
Alexey Bader <aleksey.bader@mail.ru> |
[OpenCL] Remove access qualifiers on images in arg info metadata.
Summary: Remove access qualifiers on images in arg info metadata: * kernel_arg_type * kernel_arg_base_type
Image access qualifier
[OpenCL] Remove access qualifiers on images in arg info metadata.
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
show more ...
|
#
2b0e424b |
| 01-Sep-2016 |
Honggyu Kim <hong.gyu.kim@lge.com> |
[Frontend] Fix mcount inlining bug
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 invocatio
[Frontend] Fix mcount inlining bug
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
show more ...
|
#
2bbdeacf |
| 01-Sep-2016 |
Honggyu Kim <hong.gyu.kim@lge.com> |
Remove whitespace to test commit access
llvm-svn: 280337
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1 |
|
#
7d2aecbc |
| 13-Jul-2016 |
Aaron Ballman <aaron@aaronballman.com> |
Add XRay flags to Clang. We implement two flags to control the XRay behaviour:
-fxray-instrument: enables XRay annotation of IR -fxray-instruction-threshold: configures the threshold for function si
Add XRay flags to Clang. We implement two flags to control the XRay behaviour:
-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
show more ...
|
#
10e9e598 |
| 13-Jul-2016 |
Alexey Bader <aleksey.bader@mail.ru> |
[OpenCL] Fix code generation of kernel pipe parameters.
Improved test with user define structure pipe type case.
Reviewers: Anastasia, pxli168 Subscribers: yaxunl, cfe-commits
Differential revisio
[OpenCL] Fix code generation of kernel pipe parameters.
Improved test with user define structure pipe type case.
Reviewers: Anastasia, pxli168 Subscribers: yaxunl, cfe-commits
Differential revision: http://reviews.llvm.org/D21744
llvm-svn: 275259
show more ...
|
#
5179eb78 |
| 28-Jun-2016 |
Richard Smith <richard-llvm@metafoo.co.uk> |
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11.
Instead of
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class
llvm-svn: 274049
show more ...
|
#
59f77921 |
| 24-Jun-2016 |
David Majnemer <david.majnemer@gmail.com> |
Use more ArrayRefs
No functional change is intended, just a small refactoring.
llvm-svn: 273647
|
#
b130fe7d |
| 23-Jun-2016 |
Richard Smith <richard-llvm@metafoo.co.uk> |
Implement p0292r2 (constexpr if), a likely C++1z feature.
llvm-svn: 273602
|
#
44d061a4 |
| 22-Jun-2016 |
Hans Wennborg <hans@hanshq.net> |
Add support for /Ob1 and -finline-hint-functions flags
Add support for /Ob1 (and equivalent -finline-hint-functions), which enable inlining only for functions marked inline, either explicitly (via i
Add support for /Ob1 and -finline-hint-functions flags
Add support for /Ob1 (and equivalent -finline-hint-functions), which enable inlining only for functions marked inline, either explicitly (via inline keyword, for example), or implicitly (function definition in class body, for example).
This works by enabling inlining pass, and adding noinline attribute to every function not marked inline.
Patch by Rudy Pons <rudy.pons@ilod.org>!
Differential Revision: http://reviews.llvm.org/D20647
llvm-svn: 273440
show more ...
|
#
ba28cba8 |
| 22-Jun-2016 |
Yaxun Liu <Yaxun.Liu@amd.com> |
[OpenCL] Use function metadata to represent kernel attributes
This patch uses function metadata to represent reqd_work_group_size, work_group_size_hint and vector_type_hint kernel attributes and ker
[OpenCL] Use function metadata to represent kernel attributes
This patch uses function metadata to represent reqd_work_group_size, work_group_size_hint and vector_type_hint kernel attributes and kernel argument info.
Differential Revision: http://reviews.llvm.org/D20979
llvm-svn: 273425
show more ...
|
#
f00f8032 |
| 08-Jun-2016 |
Reid Kleckner <rnk@google.com> |
[DebugInfo] Add calling conventions to DISubroutineType
Summary: This should have been a very simple change, but it was greatly complicated by the construction of new Decls during IR generation.
In
[DebugInfo] Add calling conventions to DISubroutineType
Summary: This should have been a very simple change, but it was greatly complicated by the construction of new Decls during IR generation.
In particular, we reconstruct the AST function type in order to get the implicit 'this' parameter into C++ method types.
We also have to worry about FunctionDecls whose types are not FunctionTypes because CGBlocks.cpp constructs some dummy FunctionDecls with 'void' type.
Depends on D21114
Reviewers: aprantl, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21141
llvm-svn: 272198
show more ...
|