the bits being cleared by the AND are not demanded by the BFI.
The previous BFI dag combine rule was actually incorrect (or used to be
correct until BFI representation changed).
rdar://9609030
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133034 91177308-0d34-0410-b5e6-96231b3b80d8
toString() now takes an optional bool argument that,
depending on the radix, adds the appropriate prefix
to the integer's string representation that makes it into a
meaningful C literal, e.g.:
hexademical: '-f' becomes '-0xf'
octal: '77' becomes '077'
binary: '110' becomes '0b110'
Patch by nobled@dreamwidth.org!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133032 91177308-0d34-0410-b5e6-96231b3b80d8
converted to add x,x if x is a undef. add undef, undef does not guarantee
that the resulting low order bit is zero.
Fixes <rdar://problem/9453156> and <rdar://problem/9487392>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133022 91177308-0d34-0410-b5e6-96231b3b80d8
Roman, since you're writing tests for other PPC-SVR4 vararg-related stuff, would you mind writing a test for this?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133018 91177308-0d34-0410-b5e6-96231b3b80d8
When an assembler local symbol is used but not defined in a module, a
Darwin assembler wants to issue a diagnostic to that effect.
rdar://9559714
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133010 91177308-0d34-0410-b5e6-96231b3b80d8
Dan noted that this would work on the case shown on the commit message. I think
the case that was failing was a bb ending with a redundant conditional jump:
...
jne foo
foo:
...
I was unable to find any such case in the tests or in a debug build of clang,
so I will revert this part of the patch and watch the bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133004 91177308-0d34-0410-b5e6-96231b3b80d8
types (with power of two types such as 8,16,32 .. 512).
Fix a bug in the integer promotion of bitcast nodes. Enable integer expanding
only if the target of the conversion is an integer (when the type action is
scalarize).
Add handling to the legalization of vector load/store in cases where the saved
vector is integer-promoted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132985 91177308-0d34-0410-b5e6-96231b3b80d8
sharp all or nothing transition when one extra predecessor was added. Now
we still test first ones for merging.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132974 91177308-0d34-0410-b5e6-96231b3b80d8
spartan right now, but I plan to encode more information in this enum to improve
the correctness and reliability of SRoA. At least this first pass makes it
possible to make VectorTy an actual VectorType.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132937 91177308-0d34-0410-b5e6-96231b3b80d8
The logic for reserving R4 for use as a scratch needs to match that for
actually using it. Also, it's not necessary for immediate <=508, so adjust
the value checked.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132934 91177308-0d34-0410-b5e6-96231b3b80d8
might overflow. Re-typing the alloca to a larger type (e.g. double)
hoists a shift into the alloca, potentially exposing overflow in the
expression. rdar://problem/9265821
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132926 91177308-0d34-0410-b5e6-96231b3b80d8
intrinsics. In fact, we'll optimize a bitcast to that when possible. Detect it
when looking for the lifetime intrinsics.
No test case, noticed by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132906 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, don't spill dirty registers only to satisfy a hint. It is
not worth it.
The attached test case provides an example where the fast allocator
would spill a register when other registers are available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132900 91177308-0d34-0410-b5e6-96231b3b80d8
