This pleases the register scavenger and brings
test/CodeGen/ARM/2011-08-12-vmovqqqq-pseudo.ll a little closer to
working with -verify-machineinstrs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138164 91177308-0d34-0410-b5e6-96231b3b80d8
Therefore, rather then generate a pseudo instruction, which is later expanded,
generate the necessary instructions in place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138163 91177308-0d34-0410-b5e6-96231b3b80d8
the intent seems to be to terminate even in Release builds, just use abort()
directly.
If program flow ever reaches a __builtin_unreachable (which llvm_unreachable is
#define'd to on newer GCCs) then the program is undefined.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138068 91177308-0d34-0410-b5e6-96231b3b80d8
Normally, a partial register def is treated as reading the
super-register unless it also defines the full register like this:
%vreg110:sub_32bit<def> = COPY %vreg77:sub_32bit, %vreg110<imp-def>
This patch also uses the <undef> flag on partial defs to recognize
non-reading operands:
%vreg110:sub_32bit<def,undef> = COPY %vreg77:sub_32bit
This fixes a subtle bug in RegisterCoalescer where LIS->shrinkToUses
would treat a coalesced copy as still reading the register, extending
the live range artificially.
My test case only works when I disable DCE so a dead copy is left for
RegisterCoalescer, so I am not including it.
<rdar://problem/9967101>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138018 91177308-0d34-0410-b5e6-96231b3b80d8
known-incremented level, because the two concepts can be used
to prove the saftey of a retain+release removal in different
ways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138016 91177308-0d34-0410-b5e6-96231b3b80d8
We have to be careful when splitting the landing pad block, because the
landingpad instruction is required to remain as the first non-PHI of an invoke's
unwind edge. To retain this, we split the block into two blocks, moving the
predecessors within the loop to one block and the remaining predecessors to the
other. The landingpad instruction is cloned into the new blocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138015 91177308-0d34-0410-b5e6-96231b3b80d8
SplitLandingPadPredecessors is similar to SplitBlockPredecessors in that it
splits the current block and attaches a set of predecessors to the new basic
block. However, it differs from SplitBlockPredecessors in that it's specifically
designed to handle landing pad blocks.
Two new basic blocks are created: one that is has the vector of predecessors as
its predecessors and one that has the remaining predecessors as its
predecessors. Those two new blocks then receive a cloned copy of the landingpad
instruction from the original block. The landingpad instructions are joined in a
PHI, etc. Like SplitBlockPredecessors, it updates the LLVM IR, AliasAnalysis,
DominatorTree, DominanceFrontier, LoopInfo, and LCCSA analyses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138014 91177308-0d34-0410-b5e6-96231b3b80d8
instead of 2. They were already defined this way in their regular
version, but not for the intrinsics versions (*_Int), and that would work
for assembly emission but not for object code, since a MachineOperand
would be missing. This commit fix PR10697.
Also removed the {VSQRT,VRSQRT,VRCP}r_Int forms and match the intrinsic
via INSERT_SUBREG+EXTRACT_SUBREG patterns. The same couldn't be done for
memory versions because sse_load_f32/sse_load_f64 operand need special
handling and don't work like regular "addr" operands.
There are right now 114 "*_Int" and 98 "Int_*" forms! I'm slowly
removing them as I step through, but hope we can get rid of these
someday, they are really annoying :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138012 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support of NativeClient (*-*-nacl) OS support to LLVM.
It's already supported in autoconf/config.sub.
The motivation for this change is to start upstreaming PNaCl work. The
whole set of patches include llvm backends (i686, x86_64, ARM),
llvm-gcc (probably, would not be upstreamed because it's deprecated)
and clang (the work has been just started, the amount of changes is
going to be low and the most of the work is expected to be done close
to the mainline).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138005 91177308-0d34-0410-b5e6-96231b3b80d8
