git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125412 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125411 91177308-0d34-0410-b5e6-96231b3b80d8

unsigned overflow (e.g. "gep P, -1"), and while they can have
signed wrap in theoretical situations, modelling an AddRec as
not having signed wrap is going enough for any case we can 
think of today.  In the future if this isn't enough, we can
revisit this.  Modeling them as having NUW isn't causing any
known problems either FWIW.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125410 91177308-0d34-0410-b5e6-96231b3b80d8

unsigned overflow (e.g. due to a negative array index), but
the scales on array size multiplications are known to not
sign wrap.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125409 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125408 91177308-0d34-0410-b5e6-96231b3b80d8

on the host OS.  Reviewed by dgregor.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125406 91177308-0d34-0410-b5e6-96231b3b80d8

This avoids moving each element to the integer register file and calling __divsi3 etc. on it.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125402 91177308-0d34-0410-b5e6-96231b3b80d8

that the condition is not a vector.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125398 91177308-0d34-0410-b5e6-96231b3b80d8

Add more folding patterns to constant expressions of vector selects and vector
bitcasts.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125393 91177308-0d34-0410-b5e6-96231b3b80d8

Fix #9190

The bug happens when the DAGCombiner attempts to optimize one of the patterns
of the SUB opcode. It tries to create a zero of type v2i64. This type is legal
on 32bit machines, but the initializer of this vector (i64) is target dependent.
Currently, the initializer attempts to create an i64 zero constant, which fails.
Added a flag to tell the DAGCombiner to create a legal zero, if we require that
the pass would generate legal types.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125391 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125389 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125388 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125385 91177308-0d34-0410-b5e6-96231b3b80d8

objects, since they'll end up using the implicit conversion to "bool"
and causing some very "fun" surprises.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125380 91177308-0d34-0410-b5e6-96231b3b80d8

a loop when unswitching it. It only does this in the complex case, because
everything should be fine already in the simple case.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125369 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125368 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125367 91177308-0d34-0410-b5e6-96231b3b80d8

flag.  Noticed by Jin Gu Kang!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125366 91177308-0d34-0410-b5e6-96231b3b80d8

as other constantexpr flags, reducing redundancy.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125365 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125363 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125361 91177308-0d34-0410-b5e6-96231b3b80d8

This
define float @foo(float %x, float %y) nounwind readnone {
entry:
  %0 = tail call float @copysignf(float %x, float %y) nounwind readnone
  ret float %0
}

Was compiled to:
    vmov     s0, r1
    bic      r0, r0, #-2147483648
    vmov     s1, r0
    vcmpe.f32    s0, #0
    vmrs         apsr_nzcv, fpscr
    it           lt
    vneglt.f32   s1, s1
    vmov         r0, s1
    bx           lr

This fails to copy the sign of -0.0f because it's lost during the float to int
conversion. Also, it's sub-optimal when the inputs are in GPR registers.

Now it uses integer and + or operations when it's profitable. And it's correct!
    lsrs    r1, r1, #31
    bfi     r0, r1, #31, #1
    bx      lr
rdar://8984306


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125357 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125327 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125325 91177308-0d34-0410-b5e6-96231b3b80d8

passes. Fixes PR9112. Patch by Jakub Staszak!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125319 91177308-0d34-0410-b5e6-96231b3b80d8

iv-users twice.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125318 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125317 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125316 91177308-0d34-0410-b5e6-96231b3b80d8

[AVX] Implement 256-bit vector lowering for SCALAR_TO_VECTOR.  This
largely completes support for 128-bit fallback lowering for code that
is not 256-bit ready.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125315 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125305 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125304 91177308-0d34-0410-b5e6-96231b3b80d8

Fix a lot of o32 CC issues and add a bunch of tests. Patch by Akira Hatanaka with some small modifications by me.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125292 91177308-0d34-0410-b5e6-96231b3b80d8

[AVX] Implement 256-bit vector lowering for EXTRACT_VECTOR_ELT.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125284 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125279 91177308-0d34-0410-b5e6-96231b3b80d8

Unixen and Cygwin do not need it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125277 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125274 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125273 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125272 91177308-0d34-0410-b5e6-96231b3b80d8

gep to explicit addressing, we know that none of the intermediate
computation overflows.

This could use review: it seems that the shifts certainly wouldn't
overflow, but could the intermediate adds overflow if there is a 
negative index?

Previously the testcase would instcombine to:

define i1 @test(i64 %i) {
  %p1.idx.mask = and i64 %i, 4611686018427387903
  %cmp = icmp eq i64 %p1.idx.mask, 1000
  ret i1 %cmp
}

now we get:

define i1 @test(i64 %i) {
  %cmp = icmp eq i64 %i, 1000
  ret i1 %cmp
}



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125271 91177308-0d34-0410-b5e6-96231b3b80d8

for NSW/NUW binops to follow the pattern of exact binops.  This
allows someone to use Builder.CreateAdd(x, y, "tmp", MaybeNUW);


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125270 91177308-0d34-0410-b5e6-96231b3b80d8