llvm-svn: 141001

Treat VEX.vvvv as a 3-bit field outside of 64-bit mode. Prevents access to registers xmm8-xmm15 outside 64-bit mode.

llvm-svn: 140997

llvm-svn: 140994

llvm-svn: 140993

logic by David Meyer revealed this bug.

llvm-svn: 140992

llvm-svn: 140991

llvm-svn: 140980

llvm-svn: 140979

Fix some Intel syntax disassembly issues with instructions that implicitly use AL/AX/EAX/RAX such as ADD/SUB/ADC/SUBB/XOR/OR/AND/CMP/MOV/TEST.

llvm-svn: 140974

Special case disassembler handling of REX.B prefix on NOP instruction to decode as XCHG R8D, EAX instead. Fixes PR10344.

llvm-svn: 140971

r140966.

llvm-svn: 140969

but not load instructions. Noticed by inspection.

llvm-svn: 140966

llvm-svn: 140962

llvm-svn: 140959

llvm-svn: 140955

Fix disassembler handling of CRC32 which is an odd instruction that uses 0xf2 as an opcode extension and allows the opsize prefix. This necessitated adding IC_XD_OPSIZE and IC_64BIT_XD_OPSIZE contexts. Unfortunately, this increases the size of the disassembler tables. Fixes PR10702.

llvm-svn: 140954

to appease nightly testers.  Not quite there yet.

llvm-svn: 140953

Moved type construction out of the loop and added an assert on the legality of the type. Formatted lines to the 80 char limit.

llvm-svn: 140952

This is the first step towards splitting LLVM and Clang's tblgen executables.

llvm-svn: 140951

llvm-svn: 140947

llvm-svn: 140946

llvm-svn: 140943

llvm-svn: 140942

llvm-svn: 140941

llvm-svn: 140940

llvm-svn: 140939

Add an ARMConstantPool class for external symbols. This will split out the support for external symbols from the base class.

llvm-svn: 140938

llvm-svn: 140937

and block addresses.

llvm-svn: 140936

* Add a couple of Create methods to the ARMConstantPoolConstant class,
* Add its own version of getExistingMachineCPValue, and
* Modify hasSameValue to return false if the object isn't an ARMConstantPoolConstant.

llvm-svn: 140935

llvm-svn: 140934

pool value.

It's not used right now, but will be soon.

llvm-svn: 140933

llvm-svn: 140928

useful if an optimization assumes the stack has been realigned.  Credit to
Eli for his assistance.
rdar://10043857

llvm-svn: 140924

We want heuristics to be based on accurate data, but more importantly
we don't want llvm to behave randomly. A benign trunc inserted by an
upstream pass should not cause a wild swings in optimization
level. See PR11034. It's a general problem with threshold-based
heuristics, but we can make it less bad.

llvm-svn: 140919

llvm-svn: 140916

llvm-svn: 140906

All the sub-class bit vectors are computed when first creating the
register bank.

llvm-svn: 140905

llvm-svn: 140904

llvm-svn: 140903