|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| | llvm-svn: 95170 | 
| | 
| 
| 
| | llvm-svn: 95165 | 
| | 
| 
| 
| | llvm-svn: 95154 | 
| | 
| 
| 
| | llvm-svn: 95147 | 
| | 
| 
| 
| 
| 
| | Passed bootstrap and nightly test run here.
llvm-svn: 95145 | 
| | 
| 
| 
| 
| 
| 
| | for vectors.  Codegen is generating awful code or segfaulting
in various cases (e.g. PR6204).
llvm-svn: 95058 | 
| | 
| 
| 
| | llvm-svn: 95055 | 
| | 
| 
| 
| 
| 
| | when the cast is extending.
llvm-svn: 95046 | 
| | 
| 
| 
| 
| 
| | don't use TargetData here.
llvm-svn: 95040 | 
| | 
| 
| 
| | llvm-svn: 95036 | 
| | 
| 
| 
| | llvm-svn: 95035 | 
| | 
| 
| 
| | llvm-svn: 95027 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | disabled by default.  This divides the existing load PRE code into 2 phases:
first it checks that it is safe to move the load to each of the predecessors
where it is unavailable, and then if it is safe, the code is changed to move
the load.  Radar 7571861.
llvm-svn: 95007 | 
| | 
| 
| 
| | llvm-svn: 94995 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | of objc message send was getting marked arm_apcscc, but the prototype
isn't.  This is fine at runtime because objcmsgsend is implemented in
assembly.  Only turn a mismatched caller and callee into 'unreachable'
if the callee is a definition.
llvm-svn: 94986 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | case, instcombine can't zap the invoke for fear of changing the CFG.
However, we have to do something to prevent the next iteration of
instcombine from inserting another store -> undef before the invoke
thereby getting into infinite iteration between dead store elim and
store insertion.
Just zap the callee to null, which will prevent the next iteration
from doing anything.
llvm-svn: 94985 | 
| | 
| 
| 
| 
| 
| 
| | The testcase from pr6198 does not crash for me -- I don't know what's up with
that -- so I'm not adding it to the tests.
llvm-svn: 94984 | 
| | 
| 
| 
| | llvm-svn: 94943 | 
| | 
| 
| 
| 
| 
| | use and X is free to negate.
llvm-svn: 94941 | 
| | 
| 
| 
| 
| 
| | 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 |