llvm-svn: 94863

This bug was exposed by my inliner cost changes in r94615, and caused failures
of lencod on most architectures when building with LTO.

This patch fixes lencod and 464.h264ref on x86-64 (and likely others).

llvm-svn: 94858

create a testcase where this matters.  The select+load transformation only
occurs when isSafeToLoadUnconditionally is true, and in those situations,
instcombine also changes the underlying objects to be aligned.  This seems
like a good idea regardless, and I've verified that it doesn't pessimize
the subsequent realignment.

llvm-svn: 94850

llvm-svn: 94841

llvm-svn: 94835

indices are safe if the result is known to be within the bounds of the
underlying object.

llvm-svn: 94829

(via APInt &RHSKnownZero = KnownZero, etc) seems dangerous and confusing to me: it
is easy not to notice this, and then wonder why KnownZero/RHSKnownZero changed
underneath you when you modified RHSKnownZero/KnownZero etc.  So get rid of this.
No intended functionality change (tested with "make check" + llvm-gcc bootstrap).

llvm-svn: 94802

llvm-svn: 94783

lowering. We'll either figure it out, or not and be lowered by
SelectionDAGBuild.

Add test.

llvm-svn: 94775

llvm-svn: 94771

llvm-svn: 94765

llvm-svn: 94763

when it should have been and'd with LowBits.  Fix that and while there beef
up the logic in the case of a negative LHS.

llvm-svn: 94745

This was already being done in SSAUpdater::GetValueAtEndOfBlock so I've
just changed SSAUpdater to check for existing PHIs in both places.

llvm-svn: 94690

Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.

Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods.  The bindings to
other languages still use the ModuleProvider concept.  It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.

Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.

llvm-svn: 94686

llvm-svn: 94684

llvm-svn: 94683

llvm-svn: 94649

llvm-svn: 94648

llvm-svn: 94634

llvm-svn: 94618

llvm-svn: 94567

In mem2reg, for all alloca/stores that get promoted where the alloca has an associated llvm.dbg.declare instrinsic, insert an llvm.dbg.var intrinsic before each store.

llvm-svn: 94493

already checked that TmpBB->getSinglePredecessor() is non-null.

llvm-svn: 94451

parameter with a default value, instead of just hardcoding it in the
implementation.  The limit of MaxLookup = 6 was introduced in r69151 to fix
a performance problem with O(n^2) behavior in instcombine, but the scalarrepl
pass is relying on getUnderlyingObject to go all the way back to an AllocaInst.
Making the limit part of the method signature makes it clear that by default
the result is limited and should help avoid similar problems in the future.
This fixes pr6126.

llvm-svn: 94433

llvm-svn: 94432

llvm-svn: 94378

"sext cond" instead of a select.  This simplifies some instcombine
code, matches the policy for zext (cond ? 1 : 0 -> zext), and allows
us to generate better code for a testcase on ppc.

llvm-svn: 94339

llvm-svn: 94336

llvm-svn: 94331

for arbitrary terminators in predecessors, don't assume
it is a conditional or uncond branch.  The testcase shows
an example where they can happen with switches.

llvm-svn: 94323

externally visible function, it can still find all callers of it and replace
the parameters to a dead argument with undef.

llvm-svn: 94322

handle the case when we can infer an input to the xor
from all inputs that agree, instead of going into an
infinite loop.  Another part of PR6199

llvm-svn: 94321

llvm-svn: 94319

readme forever.

llvm-svn: 94318

for strcpy.

llvm-svn: 94287

In mem2reg, for all alloca/stores that get promoted where the alloca has an associated llvm.dbg.declare instrinsic, insert an llvm.dbg.var intrinsic before each store

llvm-svn: 94260

llvm-svn: 94203

test on ARM.

llvm-svn: 94198

llvm-svn: 94194