Copy noalias metadata from call sites to inlined instructions

When a call site with noalias metadata is inlined, that metadata can be
propagated directly to the inlined instructions (only those that

Copy noalias metadata from call sites to inlined instructions

When a call site with noalias metadata is inlined, that metadata can be
propagated directly to the inlined instructions (only those that might access
memory because it is not useful on the others). Prior to inlining, the noalias
metadata could express that a call would not alias with some other memory
access, which implies that no instruction within that called function would
alias. By propagating the metadata to the inlined instructions, we preserve
that knowledge.

This should complete the enhancements requested in PR20500.

llvm-svn: 215676

show more ...

Add noalias metadata for general calls (not just memory intrinsics) during inlining

When preserving noalias function parameter attributes by adding noalias
metadata in the inliner, we should do this

Add noalias metadata for general calls (not just memory intrinsics) during inlining

When preserving noalias function parameter attributes by adding noalias
metadata in the inliner, we should do this for general function calls (not just
memory intrinsics). The logic is very similar to what already existed (except
that we want to add this metadata even for functions taking no relevant
parameters). This metadata can be used by ModRef queries in the caller after
inlining.

This addresses the first part of PR20500. Adding noalias metadata during
inlining is still turned off by default.

llvm-svn: 215657

show more ...

Move helper for getting a terminating musttail call to BasicBlock

No functional change. To be used in future commits that need to look
for such instructions.

Reviewed By: rafael

Differential Revi

Move helper for getting a terminating musttail call to BasicBlock

No functional change. To be used in future commits that need to look
for such instructions.

Reviewed By: rafael

Differential Revision: http://reviews.llvm.org/D4504

llvm-svn: 215413

show more ...

Convert noalias parameter attributes into noalias metadata during inlining

This functionality is currently turned off by default.

Part of the motivation for introducing scoped-noalias metadata is t

Convert noalias parameter attributes into noalias metadata during inlining

This functionality is currently turned off by default.

Part of the motivation for introducing scoped-noalias metadata is to enable the
preservation of noalias parameter attribute information after inlining.
Sometimes this can be inferred from the code in the caller after inlining, but
often we simply lose valuable information.

The overall process if fairly simple:
1. Create a new unqiue scope domain.
2. For each (used) noalias parameter, create a new alias scope.
3. For each pointer, collect the underlying objects. Add a noalias scope for
each noalias parameter from which we're not derived (and has not been
captured prior to that point).
4. Add an alias.scope for each noalias parameter from which we might be
derived (or has been captured before that point).

Note that the capture checks apply only if one of the underlying objects is not
an identified function-local object.

llvm-svn: 213949

show more ...

Add scoped-noalias metadata

This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To prov

Add scoped-noalias metadata

This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers

Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.

What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:

!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }

Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:

... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }

When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.

Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.

[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]

Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.

llvm-svn: 213864

show more ...

DebugInfo: Preserve debug location information when transforming a call into an invoke during inlining.

This both improves basic debug info quality, but also fixes a larger
hole whenever we inline a

DebugInfo: Preserve debug location information when transforming a call into an invoke during inlining.

This both improves basic debug info quality, but also fixes a larger
hole whenever we inline a call/invoke without a location (debug info for
the entire inlining is lost and other badness that the debug info
emission code is currently working around but shouldn't have to).

llvm-svn: 212065

show more ...

Fix line numbers for code inlined from __nodebug__ functions.

Instructions from __nodebug__ functions don't have file:line
information even when inlined into no-nodebug functions. As a result,
intri

Fix line numbers for code inlined from __nodebug__ functions.

Instructions from __nodebug__ functions don't have file:line
information even when inlined into no-nodebug functions. As a result,
intrinsics (SSE and other) from <*intrin.h> clang headers _never_
have file:line information.

With this change, an instruction without !dbg metadata gets one from
the call instruction when inlined.

Fixes PR19001.

llvm-svn: 210459

show more ...

Don't insert lifetime.end markers between a musttail call and ret

The allocas going out of scope are immediately killed by the return
instruction.

This is a resend of r208912, which was committed a

Don't insert lifetime.end markers between a musttail call and ret

The allocas going out of scope are immediately killed by the return
instruction.

This is a resend of r208912, which was committed accidentally.

Reviewers: chandlerc

Differential Revision: http://reviews.llvm.org/D3792

llvm-svn: 208920

show more ...

Revert "Don't insert lifetime.end markers between a musttail call and ret"

This reverts commit r208912.

It was committed accidentally without review.

llvm-svn: 208914

Remove unused variable in inliner

We have to iterate over all the calls that were inlined to find out if
any were musttail.

Sink another variable down to where its used.

llvm-svn: 208913

Don't insert lifetime.end markers between a musttail call and ret

The allocas going out of scope are immediately killed by the return
instruction.

Reviewers: chandlerc

Differential Revision: http:

Don't insert lifetime.end markers between a musttail call and ret

The allocas going out of scope are immediately killed by the return
instruction.

Reviewers: chandlerc

Differential Revision: http://reviews.llvm.org/D3630

llvm-svn: 208912

show more ...

Teach the inliner how to preserve musttail invariants

The interesting case is what happens when you inline a musttail call
through a musttail call site. In this case, we can't break perfect
forward

Teach the inliner how to preserve musttail invariants

The interesting case is what happens when you inline a musttail call
through a musttail call site. In this case, we can't break perfect
forwarding or allow any stack growth.

Instead of merging control flow from the inlined return instruction
after a musttail call into the body of the caller, leave the inlined
return instruction in the caller so that the musttail call stays in the
tail position.

More work is required in http://reviews.llvm.org/D3630 to handle the
case where the inlined function has dynamic allocas or byval arguments.

Reviewers: chandlerc

Differential Revision: http://reviews.llvm.org/D3491

llvm-svn: 208910

show more ...

[C++] Use 'nullptr'. Transforms edition.

llvm-svn: 207196

Remove more default address space argument usage.

These places are inconsequential in practice.

llvm-svn: 207021

Fix PR7272 in -tailcallelim instead of the inliner

The -tailcallelim pass should be checking if byval or inalloca args can
be captured before marking calls as tail calls. This was the real root
cau

Fix PR7272 in -tailcallelim instead of the inliner

The -tailcallelim pass should be checking if byval or inalloca args can
be captured before marking calls as tail calls. This was the real root
cause of PR7272.

With a better fix in place, revert the inliner change from r105255. The
test case it introduced still passes and has been moved to
test/Transforms/Inline/byval-tail-call.ll.

Reviewers: chandlerc

Differential Revision: http://reviews.llvm.org/D3403

llvm-svn: 206789

show more ...

Add lifetime markers for allocas created to hold byval arguments, make them
appear in the InlineFunctionInfo.

llvm-svn: 206308

Split byval argument initialization so the memcpy(s) are injected at the
beginning of the first new block after inlining.

llvm-svn: 206307

[C++11] Add range based accessors for the Use-Def chain of a Value.

This requires a number of steps.
1) Move value_use_iterator into the Value class as an implementation
detail
2) Change it to ac

[C++11] Add range based accessors for the Use-Def chain of a Value.

This requires a number of steps.
1) Move value_use_iterator into the Value class as an implementation
detail
2) Change it to actually be a *Use* iterator rather than a *User*
iterator.
3) Add an adaptor which is a User iterator that always looks through the
Use to the User.
4) Wrap these in Value::use_iterator and Value::user_iterator typedefs.
5) Add the range adaptors as Value::uses() and Value::users().
6) Update *all* of the callers to correctly distinguish between whether
they wanted a use_iterator (and to explicitly dig out the User when
needed), or a user_iterator which makes the Use itself totally
opaque.

Because #6 requires churning essentially everything that walked the
Use-Def chains, I went ahead and added all of the range adaptors and
switched them to range-based loops where appropriate. Also because the
renaming requires at least churning every line of code, it didn't make
any sense to split these up into multiple commits -- all of which would
touch all of the same lies of code.

The result is still not quite optimal. The Value::use_iterator is a nice
regular iterator, but Value::user_iterator is an iterator over User*s
rather than over the User objects themselves. As a consequence, it fits
a bit awkwardly into the range-based world and it has the weird
extra-dereferencing 'operator->' that so many of our iterators have.
I think this could be fixed by providing something which transforms
a range of T&s into a range of T*s, but that *can* be separated into
another patch, and it isn't yet 100% clear whether this is the right
move.

However, this change gets us most of the benefit and cleans up
a substantial amount of code around Use and User. =]

llvm-svn: 203364

show more ...

[Layering] Move DebugInfo.h into the IR library where its implementation
already lives.

llvm-svn: 203046

[Modules] Move CallSite into the IR library where it belogs. It is
abstracting between a CallInst and an InvokeInst, both of which are IR
concepts.

llvm-svn: 202816

Rename some member variables from TD to DL.

TargetData was renamed DataLayout back in r165242.

llvm-svn: 201581

Fix inlining to not lose the "cleanup" clause from landingpads

This fixes PR17872. This bug can lead to C++ destructors not being
called when they should be, when an exception is thrown.

llvm-svn:

Fix inlining to not lose the "cleanup" clause from landingpads

This fixes PR17872. This bug can lead to C++ destructors not being
called when they should be, when an exception is thrown.

llvm-svn: 196711

show more ...

Fix inlining to not produce duplicate landingpad clauses

Before this change, inlining one "invoke" into an outer "invoke" call
site can lead to the outer landingpad's catch/filter clauses being
copi

Fix inlining to not produce duplicate landingpad clauses

Before this change, inlining one "invoke" into an outer "invoke" call
site can lead to the outer landingpad's catch/filter clauses being
copied multiple times into the resulting landingpad. This happens:

* when the inlined function contains multiple "resume" instructions,
because forwardResume() copies the clauses but is called multiple
times;

* when the inlined function contains a "resume" and a "call", because
HandleCallsInBlockInlinedThroughInvoke() copies the clauses but is
redundant with forwardResume().

Fix this by deduplicating the code.

This problem doesn't lead to any incorrect execution; it's only
untidy.

This change will make fixing PR17872 a little easier.

llvm-svn: 196710

show more ...

InlineFunction.cpp: Remove a return value that is always false

Remove some associated dead code.

This cleanup is associated with PR17872.

llvm-svn: 196147

Revert "Inliner: Handle readonly attribute per argument when adding memcpy"

This reverts commit r193356, it caused PR17781.

A reduced test case covering this regression has been added to the test s

Revert "Inliner: Handle readonly attribute per argument when adding memcpy"

This reverts commit r193356, it caused PR17781.

A reduced test case covering this regression has been added to the test suite.

llvm-svn: 193955

show more ...