| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
there are clearly no stores between the load and the store. This fixes
this miscompile reported as PR7833.
This breaks the test/CodeGen/X86/narrow_op-2.ll optimization, which is
safe, but awkward to prove safe. Move it to X86's README.txt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112861 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
ConstantFoldBIT_CONVERTofBUILD_VECTOR calling itself
recursively and returning a SCALAR_TO_VECTOR node, but assuming the input was always a BUILD_VECTOR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109519 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108688 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
conversions around sqrt instructions.
I am assured by people more knowledgeable than me that there are no rounding issues in eliminating this.
This fixed <rdar://problem/8197504>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108639 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108130 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
disabled and then never turned back on again. Adjust some tests, one because
this change avoids an unnecessary instruction, and the other to make it
continue testing what it was intended to test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107941 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
few more idioms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107868 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
for consistency sake.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107820 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107710 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
can't be changed arbitrarily by the DAGCombiner without checking if it is
running after legalization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107097 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
is not used. Spotted by gcc-4.6.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
DAGCombiner pass,"... it was causing both 'file' (with clang) and 176.gcc (with llvm-gcc) to be miscompiled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106634 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
atomic intrinsics, either because the use locking instructions for the
atomics, or because they perform the locking directly. Add support in the
DAG combiner to fold away the fences.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106630 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
which is faster, simpler, and less surprising.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106263 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
Mon Ping provided; unfortunately bugpoint failed to
reduce it, but I think it's important to have a test for
this in the suite. 8023512.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
(oye, a word which should be better known to people writing tree
traversals, means grandchild.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104619 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104410 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
so that it will continue to test what it was meant to test when I commit a
separate change for better support of BUILD_VECTOR and VECTOR_SHUFFLE for Neon.
Fix a DAG combiner crash exposed by this test change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104380 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
test/Codegen/ARM/reg_sequence.ll but it doesn't affect the generated code
because the coalescer cleans it up. Radar 7998853.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104185 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
modeled as icmp / fcmp + sext. This is turned into a vsetcc by dag combine (yes, not a good long term solution). The targets can then isel the vsetcc to the appropriate instruction.
The trouble arises when the result of a vector cmp + sext is then and'ed with all ones. Instcombine will turn it into a vector cmp + zext, dag combiner will miss turning it into a vsetcc and hell breaks loose after that.
Teach dag combine to turn a vector cpm + zest into a vsetcc + and 1. This fixes rdar://7923010.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104094 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
into the target hook. Only the target knows whether the swap is safe. In Thumb2 mode, the offset must be an immediate. rdar://7998649
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104060 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
(build_vector), (build_vector)).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104004 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
operands may be the same. PR7018. rdar://7939869.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103419 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
comparisons sign-extended to a different bitwidth than the
comparison operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102721 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
failed to do anything.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102492 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
- Catch more further dag combine opportunities as result of operand promotion, e.g. (i32 anyext (i16 trunc (i32 x))) -> (i32 x)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102455 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
of extload result truncated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102236 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
testcase yet, as the testcase now fails downstream.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102228 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102202 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
- Some code refactoring.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102111 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
it as it's not dead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101808 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101621 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
case until -promote-16bit is enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101551 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
requires target specific queries. For example, x86 should promote i16 to i32 when it does not impact load folding.
x86 support is off by default. It can be enabled with -promote-16bit.
Work in progress.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101448 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tokenfactor in between the load/store. This allows us to
optimize test7 into:
_test7: ## @test7
## BB#0: ## %entry
movl (%rdx), %eax
## kill: SIL<def> ESI<kill>
movb %sil, 5(%rdi)
ret
instead of:
_test7: ## @test7
## BB#0: ## %entry
movl 4(%esp), %ecx
movl $-65281, %eax ## imm = 0xFFFFFFFFFFFF00FF
andl 4(%ecx), %eax
movzbl 8(%esp), %edx
shll $8, %edx
addl %eax, %edx
movl 12(%esp), %eax
movl (%eax), %eax
movl %edx, 4(%ecx)
ret
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101355 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
This doesn't occur much at all, it only seems to formed in the case
when the trunc optimization kicks in due to phase ordering. In that
case it is saves a few bytes on x86-32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101350 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
and. This happens with the store->load narrowing stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101348 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a load/or/and/store sequence into a narrower store when it is
safe. Daniel tells me that clang will start producing this sort
of thing with bitfields, and this does trigger a few dozen times
on 176.gcc produced by llvm-gcc even now.
This compiles code like CodeGen/X86/2009-05-28-DAGCombineCrash.ll
into:
movl %eax, 36(%rdi)
instead of:
movl $4294967295, %eax ## imm = 0xFFFFFFFF
andq 32(%rdi), %rax
shlq $32, %rcx
addq %rax, %rcx
movq %rcx, 32(%rdi)
and each of the testcases into a single store. Each of them used
to compile into craziness like this:
_test4:
movl $65535, %eax ## imm = 0xFFFF
andl (%rdi), %eax
shll $16, %esi
addl %eax, %esi
movl %esi, (%rdi)
ret
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101343 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101334 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101010 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100639 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Makes it possible to lower with floating point loads and stores.
2. Avoid unaligned loads / stores unless it's fast.
3. Fix some memcpy lowering logic bug related to when to optimize a
load from constant string into a constant.
4. Adjust x86 memcpy lowering threshold to make it more sane.
5. Fix x86 target hook so it uses vector and floating point memory
ops more effectively.
rdar://7774704
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100090 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
when it looked past a trunc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98203 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
patch by Micah Villmow for PR6572.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98188 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
a patch my Micah Villmow for PR6465.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97692 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
long test(long x) { return (x & 123124) | 3; }
Currently compiles to:
_test:
orl $3, %edi
movq %rdi, %rax
andq $123127, %rax
ret
This is because instruction and DAG combiners canonicalize
(or (and x, C), D) -> (and (or, D), (C | D))
However, this is only profitable if (C & D) != 0. It gets in the way of the
3-addressification because the input bits are known to be zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97616 91177308-0d34-0410-b5e6-96231b3b80d8
|