| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331020 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
This reverts commit r331016, which broke a windows bot.
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/11727
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331019 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331016 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block or lambda.
This is a follow-up to r281682, which fixed a bug in computeBlockInfo
where the captured VarDecl's type, rather than the captured field type
of the enclosing lambda or block, was used to compute the layout of a
block.
This commit makes similar changes to enterBlockScope. This is necessary
to correctly determine whether a block capture requires cleanup.
rdar://problem/30388124
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295034 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290398 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
These are all emitted into a section with a cstring_literal attribute. The
attribute permits the linker to coalesce the string contents. The address of
the strings are not important.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281855 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
These strings are constants, mark them as such. This doesn't matter too much in
practice on MachO since the constants are placed into a special section and not
referred to directly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281854 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
field in the enclosing lambda or block.
This patch fixes a bug in code-gen where it uses the type of the
declared variable rather than the type of the capture of the enclosing
lambda or block for the block capture. For example, in the following
function, code-gen currently uses i32* for the block capture "a" because
"a" is passed to foo1 as a reference, but it should use i32 since the
enclosing lambda captures "a" by value.
void foo1(int &a) {
auto lambda = [a]{
auto block1 = ^{
i = a;
};
block1();
};
lambda();
}
rdar://problem/18586386
Differential Revision: https://reviews.llvm.org/D21104
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281682 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
(migration for recent LLVM change to textual IR for calls)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235147 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230795 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230783 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.
The advantages of the change are that
* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.
* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226751 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
Simply marking the symbol private conveys the desire to hide them to LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221451 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In llvm the only semantic difference between internal and private is that llvm
tries to hide private globals my mangling them with a private prefix. Since
the globals changed by this patch already had the magic don't mangle marker,
there should be no change in the generated assembly.
A followup patch should then be able to drop the \01L and \01l prefixes and let
llvm mangle as appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202419 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
tests fail.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188447 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
| |
Using CurFuncDecl is both correct and simple compared to crawling
the DeclContexts of the block.
Fixes <rdar://problem/14415072>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186210 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183942 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a lambda.
Bug #1 is that CGF's CurFuncDecl was "stuck" at lambda invocation
functions. Fix that by generally improving getNonClosureContext
to look through lambdas and captured statements but only report
code contexts, which is generally what's wanted. Audit uses of
CurFuncDecl and getNonClosureAncestor for correctness.
Bug #2 is that lambdas weren't specially mapping 'self' when inside
an ObjC method. Fix that by removing the requirement for that
and using the normal EmitDeclRefLValue path in LoadObjCSelf.
rdar://13800041
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181000 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176145 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
This reverts commit 176009.
The commit is a likely cause of several buildbot failures.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176044 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
This is an ongoing process. Any command line option which a back-end cares about
should be added here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176009 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
function attributes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175606 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
The back-end will use these values to reconfigure code generation for different
features.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175308 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
literal helper functions. All helper functions (global
and locals) use block_invoke as their prefix. Local literal
helper names are prefixed by their enclosing mangled function
names. Blocks in non-local initializers (e.g. a global variable
or a C++11 field) are prefixed by their mangled variable name.
The descriminator number added to end of the name starts off
with blank (for first block) and _<N> (for the N+2-th block).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159206 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
says.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151853 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
| |
generated block literal for lambdas which are immediately converted to block pointer type. This simplifies the AST, avoids an unnecessary copy of the lambda and makes it much easier to avoid copying the result onto the heap.
Note that this transformation has a substantial semantic effect outside of ARC: it gives the converted lambda lifetime semantics similar to a block literal. With ARC, the effect is much less obvious because the lifetime of blocks is already managed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151797 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151616 91177308-0d34-0410-b5e6-96231b3b80d8
|
