| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
longjmp and it doesn't make much sense for performance reason. If my logic is faulty, please let me know.
llvm-svn: 94937
|
| |
|
|
|
|
|
| |
unconditionally. Besides checking the offset, also check that the underlying
object is aligned as much as the load itself.
llvm-svn: 94875
|
| |
|
|
| |
llvm-svn: 94863
|
| |
|
|
|
|
|
|
|
|
|
| |
AllUsesOfValueWillTrapIfNull().
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
|
| |
|
|
|
|
|
|
|
|
|
| |
KnownOne
(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
|
| |
|
|
|
|
| |
metadata to dbg.value
llvm-svn: 94634
|
| |
|
|
| |
llvm-svn: 94618
|
| |
|
|
| |
llvm-svn: 94567
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
missing ones are libsupport, libsystem and libvmcore. libvmcore is
currently blocked on bugpoint, which uses EH. Once it stops using
EH, we can switch it off.
This #if 0's out 3 unit tests, because gtest requires RTTI information.
Suggestions welcome on how to fix this.
llvm-svn: 94164
|
| |
|
|
| |
llvm-svn: 94123
|
| |
|
|
| |
llvm-svn: 94114
|
| |
|
|
| |
llvm-svn: 94113
|
| |
|
|
| |
llvm-svn: 94112
|
| |
|
|
|
|
| |
looking for them in use iterations and remove OnlyUsedByDbgInfoIntrinsics()
llvm-svn: 94111
|
| |
|
|
|
|
|
|
| |
loop-variant components, adds must be inserted after the increment.
Keep track of the increment position for this case, and insert
these adds in the correct location.
llvm-svn: 94110
|
| |
|
|
| |
llvm-svn: 94108
|