Target DataLayout incorrectly. For now, we'll trust that the module has
got the correct DataLayout. In the future, this needs to be changed to
tell the TargetData to be "current host".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34947 91177308-0d34-0410-b5e6-96231b3b80d8
field, of type APInt, instead of multiple integer fields. Also, get rid of
the special endianness code in StoreValueToMemory and LoadValueToMemory.
ExecutionEngine is always used to execute on the host platform so this is
now unnecessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34946 91177308-0d34-0410-b5e6-96231b3b80d8
preserve dominator info then it should update parent FPPassManager's
available analysis info to reflect this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34942 91177308-0d34-0410-b5e6-96231b3b80d8
current active pass manager is appropriate or not.
A loop pass may consider current LPPassManager in appropraite if loop
pass is not preserving analysis information that is used by other
passes managed by current LPPassManager. In such situation, loop pass
can pop current LPPassManager from the PMStack using this hook
and use new LPPassManager for itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34941 91177308-0d34-0410-b5e6-96231b3b80d8
last user when one of the managed pass uses info provided by parent pass
manager.
This was exposed by LPPassManager work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34936 91177308-0d34-0410-b5e6-96231b3b80d8
scalarrepl things down to elements, but mem2reg can't promote elements that
are memset/memcpy'd. Until then, the code is disabled "0 &&".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34924 91177308-0d34-0410-b5e6-96231b3b80d8
addc, turn it into add.
This allows us to compile:
long long test(long long A, unsigned B) {
return (A + ((long long)B << 32)) & 123;
}
into:
_test:
movl $123, %eax
andl 4(%esp), %eax
xorl %edx, %edx
ret
instead of:
_test:
xorl %edx, %edx
movl %edx, %eax
addl 4(%esp), %eax ;; add of zero
andl $123, %eax
ret
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34909 91177308-0d34-0410-b5e6-96231b3b80d8
would scan the entire loop body, then scan all users of instructions in the
loop, looking for users outside the loop. Now, since we know that the
loop is in LCSSA form, we know that any users outside the loop will be LCSSA
phi nodes. Just scan them.
This speeds up indvars significantly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34898 91177308-0d34-0410-b5e6-96231b3b80d8
have been removed and dealt with. The interpreter should now be able to
execute any LLVM program using any bit width.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34884 91177308-0d34-0410-b5e6-96231b3b80d8
Move the getConstantExpr function towards the end of the file so we don't
need a dozen forward declarations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34877 91177308-0d34-0410-b5e6-96231b3b80d8
ensure they are cleaned up when the stack frame exits.
2. Move a function to the Execution.cpp file where it belongs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34876 91177308-0d34-0410-b5e6-96231b3b80d8
the order that instcombine processed instructions in the testcase. The end
result is that instcombine finished with:
define i16 @test1(i16 %a) {
%tmp = zext i16 %a to i32 ; <i32> [#uses=2]
%tmp21 = lshr i32 %tmp, 8 ; <i32> [#uses=1]
%tmp5 = shl i32 %tmp, 8 ; <i32> [#uses=1]
%tmp.upgrd.32 = or i32 %tmp21, %tmp5 ; <i32> [#uses=1]
%tmp.upgrd.3 = trunc i32 %tmp.upgrd.32 to i16 ; <i16> [#uses=1]
ret i16 %tmp.upgrd.3
}
which can't get matched as a bswap.
This patch makes instcombine more sophisticated about removing truncating
casts, allowing it to turn this into:
define i16 @test2(i16 %a) {
%tmp211 = lshr i16 %a, 8
%tmp52 = shl i16 %a, 8
%tmp.upgrd.323 = or i16 %tmp211, %tmp52
ret i16 %tmp.upgrd.323
}
which then matches as bswap. This fixes bswap.ll and implements
InstCombine/cast2.ll:test[12]. This also implements cast elimination of
add/sub.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34870 91177308-0d34-0410-b5e6-96231b3b80d8
