History log of /llvm-project/clang/lib/CodeGen/CodeGenFunction.cpp (Results 426 – 450 of 1023)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1...<<11121314151617181920>>...41