Reinstate r133435 and r133449 (reverted in r133499) now that the clang
self-hosted build failure has been fixed (r133512).

llvm-svn: 133513

Revert r133435 and r133449 to appease buildbots.

llvm-svn: 133499

Change how PHINodes store their operands.

Change PHINodes to store simple pointers to their incoming basic blocks,
instead of full-blown Uses.

Note that this loses an optimization in SplitCriticalE

Change how PHINodes store their operands.

Change PHINodes to store simple pointers to their incoming basic blocks,
instead of full-blown Uses.

Note that this loses an optimization in SplitCriticalEdge(), because we
can no longer walk the use list of a BasicBlock to find phi nodes. See
the comment I removed starting "However, the foreach loop is slow for
blocks with lots of predecessors".

Extend replaceAllUsesWith() on a BasicBlock to also update any phi
nodes in the block's successors. This mimics what would have happened
when PHINodes were proper Users of their incoming blocks. (Note that
this only works if OldBB->replaceAllUsesWith(NewBB) is called when
OldBB still has a terminator instruction, so it still has some
successors.)

llvm-svn: 133435

show more ...

Use IRBuilder to make our intrinsic calls in the inliner so that we pick up
line info correctly.

llvm-svn: 132961

Use Value::stripPointerCasts instead of reinventing part of the wheel.

llvm-svn: 132954

It's possible that an all-zero GEP may be used as the argument to lifetime
intrinsics. In fact, we'll optimize a bitcast to that when possible. Detect it
when looking for the lifetime intrinsics.

No

It's possible that an all-zero GEP may be used as the argument to lifetime
intrinsics. In fact, we'll optimize a bitcast to that when possible. Detect it
when looking for the lifetime intrinsics.

No test case, noticed by inspection.

llvm-svn: 132906

show more ...

SplitCriticalEdge can sometimes split the edge from an invoke to a landing
pad, separating the exception and selector calls from the new lpad. Teaching
it not to do that, or to properly adjust the C

SplitCriticalEdge can sometimes split the edge from an invoke to a landing
pad, separating the exception and selector calls from the new lpad. Teaching
it not to do that, or to properly adjust the CFG afterwards, is out of
scope because it would require the other edges to the landing pad to be split
as well (effectively). Instead, just recover from the most likely cases
during inlining. The best long-term solution is to change the exception
representation and commit to either requiring or not requiring the more
complex edge-splitting logic; this is just a shorter-term hack.

llvm-svn: 132799

show more ...

Teach the CallGraph to ignore calls to intrinsics.

llvm-svn: 132797

First, do no harm -- even if we can't find a selector for an enclosing
landing pad, forward llvm.eh.resume calls to it instead of turning them
invalidly into invokes.

llvm-svn: 132382

Fix this to work correctly with phis; test case to follow if this successfully
fixes self-host.

llvm-svn: 132275

Implement and document the llvm.eh.resume intrinsic, which is
transformed by the inliner into a branch to the enclosing landing pad
(when inlined through an invoke). If not so optimized, it is lower

Implement and document the llvm.eh.resume intrinsic, which is
transformed by the inliner into a branch to the enclosing landing pad
(when inlined through an invoke). If not so optimized, it is lowered
DWARF EH preparation into a call to _Unwind_Resume (or _Unwind_SjLj_Resume
as appropriate). Its chief advantage is that it takes both the
exception value and the selector value as arguments, meaning that there
is zero effort in recovering these; however, the frontend is required
to pass these down, which is not actually particularly difficult.

Also document the behavior of landing pads a bit better, and make it
clearer that it's okay that personality functions don't always land at
landing pads. This is just a fact of life. Don't write optimizations that
rely on pushing things over an unwind edge.

llvm-svn: 132253

show more ...

Fix the inliner to maintain the current de facto invoke semantics:
- the selector for the landing pad must provide all available information
about the handlers, filters, and cleanups within tha

Fix the inliner to maintain the current de facto invoke semantics:
- the selector for the landing pad must provide all available information
about the handlers, filters, and cleanups within that landing pad
- calls to _Unwind_Resume must be converted to branches to the enclosing
lpad so as to avoid re-entering the unwinder when the lpad claimed it
was going to handle the exception in some way
This is quite specific to libUnwind-based unwinding. In an effort to not
interfere too badly with other unwinders, and with existing hacks in frontends,
this only triggers on _Unwind_Resume (not _Unwind_Resume_or_Rethrow) and does
nothing with selectors if it cannot find a selector call for either lpad.

llvm-svn: 132200

show more ...

Teach the inliner to emit llvm.lifetime.start/end, to scope the local variables
of the inlinee to the code representing the original function.

llvm-svn: 131838

Fix a ton of comment typos found by codespell. Patch by
Luis Felipe Strano Moraes!

llvm-svn: 129558

Remove PHINode::reserveOperandSpace(). Instead, add a parameter to
PHINode::Create() giving the (known or expected) number of operands.

llvm-svn: 128537

(Almost) always call reserveOperandSpace() on newly created PHINodes.

llvm-svn: 128535

switch the inliner alignment enforcement stuff to use the
getOrEnforceKnownAlignment function, which simplifies the code
and makes it stronger.

llvm-svn: 122555

when eliding a byval copy due to inlining a readonly function, we have
to make sure that the reused alloca has sufficient alignment.

llvm-svn: 122236

pull byval processing out to its own helper function.

llvm-svn: 122235

fix PR8769, a miscompilation by inliner when inlining a function with a byval
argument. The generated alloca has to have at least the alignment of the
byval, if not, the client may be making assumpt

fix PR8769, a miscompilation by inliner when inlining a function with a byval
argument. The generated alloca has to have at least the alignment of the
byval, if not, the client may be making assumptions that the new alloca won't
satisfy.

llvm-svn: 122234

show more ...

improve comment

llvm-svn: 120994

Simplify code. No change in functionality.

llvm-svn: 119908

Have InlineFunction use SimplifyInstruction rather than
hasConstantValue. I was leery of using SimplifyInstruction
while the IR was still in a half-baked state, which is the
reason for delaying the

Have InlineFunction use SimplifyInstruction rather than
hasConstantValue. I was leery of using SimplifyInstruction
while the IR was still in a half-baked state, which is the
reason for delaying the simplification until the IR is fully
cooked.

llvm-svn: 119494

show more ...

Be more consistent in using ValueToValueMapTy.

llvm-svn: 116387

Reapply r112091 and r111922, support for metadata linking, with a
fix: add a flag to MapValue and friends which indicates whether
any module-level mappings are being made. In the common case of
inlin

Reapply r112091 and r111922, support for metadata linking, with a
fix: add a flag to MapValue and friends which indicates whether
any module-level mappings are being made. In the common case of
inlining, no module-level mappings are needed, so MapValue doesn't
need to examine non-function-local metadata, which can be very
expensive in the case of a large module with really deep metadata
(e.g. a large C++ program compiled with -g).

This flag is a little awkward; perhaps eventually it can be moved
into the ClonedCodeInfo class.

llvm-svn: 112190

show more ...