llvm-svn: 137636

Fix problems decoding the to/from-lane NEON memory instructions, and add a comprehensive NEON decoding testcase.

llvm-svn: 137635

llvm-svn: 137632

llvm-svn: 137631

llvm-svn: 137629

llvm-svn: 137628

llvm-svn: 137627

llvm-svn: 137626

llvm-svn: 137621

llvm-svn: 137618

llvm-svn: 137615

This builds off of the current scheme, but instead of llvm.eh.exception and
llvm.eh.selector, it uses the landingpad instruction. And instead of
llvm.eh.resume, it uses the resume instruction.

Because of the invariants in the landing pad instruction, a lot of code that's
currently needed to find the appropriate intrinsic calls for an invoke
instruction won't be needed once we go to the new EH scheme. The "FIXME"s tell
us what to remove after we switch.

llvm-svn: 137576

llvm-svn: 137575

llvm-svn: 137572

when combining add and sub instructions. Patch by Pranav Bhandarkar!

llvm-svn: 137570

With libcxx, it seems <unistd.h> would not be provided. Thanks to Ryuta Suzuki.

llvm-svn: 137567

be illegal, even if the requested vector type is legal. Testcase is one of the
disabled ARM tests in the vector-select patch.

llvm-svn: 137562

Apparently we never added code to expand these pseudo instructions, and in
over a year, no one has noticed.  Our register allocator must be awesome!

llvm-svn: 137551

This caused a race condition where a thread calls ~LLVMContextImpl which calls
Module::dropAllReferences which calls begin() on an empty ilist that would
create the sentinel, which racily accesses the global context.

This can not be fixed by locking inside createSentinel because the lock would
need to be shared with all users of the global context, including those that
reside outside LLVM's own code.

llvm-svn: 137546

of the instruction.

Note that this change affects the existing non-atomic load and store
instructions; the parser now accepts both forms, and the change is noted
in the release notes.

llvm-svn: 137527

Tidy up the code a bit and push the definition of the value next to the uses
to try to minimize this sort of issue from arising again while I'm at it.

rdar://9945172

llvm-svn: 137525

llvm-svn: 137521

vectors. It operates on 128-bit elements instead of regular scalar
types. Recognize shuffles that are suitable for VPERM2F128 and teach
the x86 legalizer how to handle them.

llvm-svn: 137519

llvm-svn: 137518

llvm-svn: 137515

Partial fix for rdar://9945172.

llvm-svn: 137513

they're the correct type.

llvm-svn: 137511

Fix some remaining issues with decoding ARM-mode memory instructions, and add another batch of tests.

llvm-svn: 137502

This implements the 'landingpad' instruction. It's used to indicate that a basic
block is a landing pad. There are several restrictions on its use (see
LangRef.html for more detail). These restrictions allow the exception handling
code to gather the information it needs in a much more sane way.

This patch has the definition, implementation, C interface, parsing, and bitcode
support in it.

llvm-svn: 137501

llvm-svn: 137499

Specify fixed bit in the LDRBT encoding, which allows us to distinguish it from certain USAT16 encodings.

llvm-svn: 137494

llvm-svn: 137487

llvm-svn: 137485

integer register to a floating point register. It is not valid to interpret
the value of a floating pointer register as part of a double precision
floating point value after a single precision floating point computational
or move instruction stores its result to the register.

- In the test case, the following code is generated before this patch is
  applied:
mtc1  $zero, $f2    ; unformatted copy to $f2
mov.s $f0, $f2      ; $f0 is in single format
sdc1  $f12, 0($sp)
mov.s $f1, $f2      ; $f1 is in single format
c.eq.d  $f12, $f0   ; $f0 cannot be interpreted as double

- The following code is generated after this patch is applied:
mtc1  $zero, $f0    ; unformatted copy to $f0
mtc1  $zero, $f1    ; unformatted copy to $f1
c.eq.d  $f12, $f0   ; $f0 can be interpreted as double

Bhanu Chetlapalli and Chris Dearman at MIPS technologies reported this bug and
provided the test case.

llvm-svn: 137484

llvm-svn: 137483

llvm-svn: 137482

llvm-svn: 137481

llvm-svn: 137480

llvm-svn: 137479

llvm-svn: 137478