Remove some instructions that seem to only exist to trick the filtering checks in the disassembler table creation. Just fix up the filter to let the real instruction through instead.

llvm-svn: 192090

llvm-svn: 192089

Teach X86 asm parser that VMOVAPSrr and other VEX-encoded register to register moves should be switched from using the MRMSrcReg form to the MRMDestReg form if the source register is a 64-bit extended register and the destination register is not.

This allows the instruction to be encoded using the 2-byte VEX form instead of the 3-byte VEX form. The GNU assembler has similar behavior and instruction selection already does this.

llvm-svn: 192088

llvm-svn: 192086

This reverts commit r192070 which reverted r192069, I forgot to
regenerate the configure scripts.

llvm-svn: 192079

Fix some assert messages to say the correct opcode name. Looks like one assert got copy and pasted to many places.

llvm-svn: 192078

This is causing MinGW bots to fail.
This reverts commit r192069.

llvm-svn: 192070

Summary:
The MSVCRT deliberately sends main() code-page specific characters.
This isn't too useful to LLVM as we end up converting the arguments to
UTF-16 and subsequently attempt to use the result as, for example, a
file name.  Instead, we need to have the ability to access the Unicode
command line and transform it to UTF-8.

This has the distinct advantage over using the MSVC-specific wmain()
function as our entry point because:
 - It doesn't work on cygwin.
 - It only work on MinGW with caveats and only then on certain versions.
 - We get to keep our entry point as main(). :)

N.B.  This patch includes fixes to other parts of lib/Support/Windows
s.t. we would be able to take advantage of getting the Unicode paths.
E.G.  clang spawning clang -cc1 would want to give it Unicode arguments.

Reviewers: aaron.ballman, Bigcheese, rnk, ruiu

Reviewed By: rnk

CC: llvm-commits, ygao

Differential Revision: http://llvm-reviews.chandlerc.com/D1834

llvm-svn: 192069

This will be used to extend constructor aliases in clang.

llvm-svn: 192066

llvm-svn: 192065

Regalloc can emit unaligned spills nowadays, but we can't fold the
spills into SSE ops if we can't guarantee alignment. PR12250.

llvm-svn: 192064

Fixed load folding in VPERM2I instruction.

llvm-svn: 192063

llvm-svn: 192059

llvm-svn: 192056

in case of BLEND and added VSHUFPS patterns.

llvm-svn: 192055

This is required because i64 is a legal type but addxcc/subxcc reads icc carry bit, which are 32 bit conditional codes.

llvm-svn: 192054

addx/subx does not modify conditional codes whereas addxcc/subxx does.

llvm-svn: 192053

llvm-svn: 192046

are directly tied to the flag names in clang with no remapping in between?

llvm-svn: 192044

llvm-svn: 192042

The most likely case where this error happens is when the user specifies
too many register operands. Don't make it look like an internal LLVM bug
when we can see that the error is coming from an inline asm instruction.
For other instructions we keep the "ran out of registers" error.

llvm-svn: 192041

llvm-svn: 192040

llvm-svn: 192039

llvm-svn: 192037

When MC was first added, targets could use hasRawTextSupport to keep features
working before they were added to the MC interface.

The design goal of MC is to provide an uniform api for printing assembly and
object files. Short of relaxations and other corner cases, a object file is
just another representation of the assembly.

It was never the intention that targets would keep doing things like

if (hasRawTextSupport())
  Set flags in one way.
else
  Set flags in another way.

When they do that they create two code paths and the object file is no longer
just another representation of the assembly. This also then requires testing
with llc -filetype=obj, which is extremelly brittle.

This patch removes some of these hacks by replacing them with smaller ones.
The ARM flag setting is trivial, so I just moved it to the constructor. For
Mips, the patch adds two temporary hack directives that allow the assembly
to represent the same things as the object file was already able to.

The hope is that the mips developers will replace the hack directives with
the same ones that gas uses and drop the -print-hack-directives flag.

I will also try to implement a target streamer interface, so that we can
move this out of the common code.

In summary, for any new work, two rules of the thumb are
  * Don't use "llc -filetype=obj" in tests.
  * Don't add calls to hasRawTextSupport.

llvm-svn: 192035

llvm-svn: 192031

llvm-svn: 192028

Add OPC_CheckChildSame0-3 to the DAG isel matcher. This replaces sequences of MoveChild, CheckSame, MoveParent. Saves 846 bytes from the X86 DAG isel matcher, ~300 from ARM, ~840 from Hexagon.

llvm-svn: 192026

llvm-svn: 192025

llvm-svn: 192023

llvm-svn: 192022

llvm-svn: 192021

Patch by Ashok Thirumurthi

llvm-svn: 192020

is updated to use DITypeRef.

Move isUnsignedDIType and getOriginalTypeSize from DebugInfo.h to be static
helper functions in DwarfCompileUnit. We already have a static helper function
"isTypeSigned" in DwarfCompileUnit, and a pointer to DwarfDebug is added to
resolve the derived-from field. All three functions need to go across link
for derived-from fields, so we need to get hold of a type identifier map.

A pointer to DwarfDebug is also added to DbgVariable in order to resolve the
derived-from field.

Debug info verifier is updated to check a derived-from field is a TypeRef.
Verifier will not go across link for derived-from fields, in debug info finder,
we go across the link to add derived-from fields to types.

Function getDICompositeType is only used by dragonegg and since dragonegg does
not generate identifier for types, we use an empty map to resolve the
derived-from field.

When printing a derived-from field, we use DITypeRef::getName to either return
the type identifier or getName of the DIType.

A paired commit at clang is required due to changes to DIBuilder.

llvm-svn: 192018

llvm-svn: 192017

llvm-svn: 192016

llvm-svn: 192015

llvm-svn: 192014

pointed to by a dbg_value belonging to a function argument is eliminated
during instruction selection.
rdar://problem/15094721.

llvm-svn: 192011

llvm-svn: 192009