llvm-svn: 190259

llvm-svn: 190258

If the DAG already has only legal types, then the second round of DAG combines
is skipped. In this case VSELECT+SETCC patterns that match a more efficient
instruction (e.g. min/max) are never recognized.

This fix allows VSELECT+SETCC combines if the types are already legal before DAG
type legalization.

Reviewer: Nadav
llvm-svn: 190105

expression uses an assembler temporary symbol from an assignment.  In this case
the symbol does not have a fragment so the use of getFragment() would be NULL
and caused a crash. In the case of an assembler temporary symbol we want to use
the AliasedSymbol (if any) which will create a local relocation entry, but if
it is not an assembler temporary symbol then let it use that symbol with an
external relocation entry.

rdar://9356266

llvm-svn: 190096

Previously, the clang crash handling code would kick in and give a crash
report for these, even though they're not that sort of error.

rdar://14882264

llvm-svn: 189878

WIP: Refactor some code so that it can be called by more than just one method. No functionality change.

llvm-svn: 189849

llvm-svn: 189779

llvm-svn: 189742

llvm-svn: 189740

Specify GATHER/SCATTER as heavy instructions.

llvm-svn: 189736

llvm-svn: 189729

llvm-svn: 189728

llvm-svn: 189699

Fixed a bug where diassembling an instruction that had a prefix would cause LLVM to identify a 1-byte instruction, but then upon querying it for that 1-byte instruction would cause an undefined opcode.

llvm-svn: 189698

llvm-svn: 189673

Currently this is just the atom model with SSE4.2 enabled.

llvm-svn: 189669

llvm-svn: 189656

llvm-svn: 189654

Teach X86 backend to create BMI2 BZHI instructions from (and X, (add (shl 1, Y), -1)). Fixes PR17038.

llvm-svn: 189653

Clean up some usage of Triple.  The base class has methods for determining if the target is iOS and Linux.

llvm-svn: 189604

llvm-svn: 189580

32-bit absolute addressing in instructions likei this:

	mov $_f, %rsi

which is not supported in 64-bit mode.

rdar://8827134

llvm-svn: 189543

llvm-svn: 189472

in use supports it.

llvm-svn: 189439

For now, (defined(X86_64_JIT) && defined(__CYGWIN__)) satisfies Cygwin64.

llvm-svn: 189437

In the LLVM side, x86_64-cygwin is almost as same as x86_64-mingw32.

llvm-svn: 189436

Summary: MASM let's you do stuff like 'MOV FS:20, EAX' and 'MOV EAX, FS:20'

Reviewers: craig.topper, rnk

Reviewed By: rnk

CC: llvm-commits

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

llvm-svn: 189407

llvm-svn: 189349

llvm-svn: 189326

Revert "Fix the build broken by r189315." and "Move everything depending on Object/MachOFormat.h over to Support/MachO.h."

This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.

llvm-svn: 189321

llvm-svn: 189315

 VPSHUFD, VPERMILPS, VMOVDDUP, VMOVLHPS, VMOVHLPS, VSHUFPS, VALIGN
 single and double forms.

llvm-svn: 189215

Make sure x86 instructions using ssmem/sdmem operand types are only able to parse memory operands of the proper size in Intel syntax. Primarily affects some of sse cvt instructions.

llvm-svn: 189206

Remove some unnecessary PredicateMethod overrides. Add RenderMethod overrides to remove forwarding in the X86AsmParser code itself. No functional change.

llvm-svn: 189205

llvm-svn: 189204

First round of fixes for the x86 fixes for the x86 move accumulator from/to memory offset instructions.

-Assembly parser now properly check the size of the memory operation specified in intel syntax. So 'mov word ptr [5], al' is no longer accepted.
-x86-32 disassembly of these instructions no longer sign extends the 32-bit address immediate based on size.
-Intel syntax printing prints the ptr size and places brackets around the address immediate.

Known remaining issues with these instructions:
-Segment override prefix is not supported. PR16962 and PR16961.
-Immediate size should be changed by address size prefix.

llvm-svn: 189201

llvm-svn: 189189

Add hasSideEffects/mayLoad/mayStore flags to the X86 moffs8/moffs16/moffs32/moffs64 versions of move.

llvm-svn: 189182

llvm-svn: 189178

There is no advantage in being different and using the same names simplifies
clang a bit.

llvm-svn: 189141