The issue was that the MatchingInlineAsm and VariantID args to the
MatchInstructionImpl function weren't being set properly.  Specifically, when
parsing intel syntax, the parser thought it was parsing inline assembly in the
at&t dialect; that will never be the case.  

The crash was caused when the emitter tried to emit the instruction, but the
operands weren't set.  When parsing inline assembly we only set the opcode, not
the operands, which is used to lookup the instruction descriptor.
rdar://13854391 and PR15945

Also, this commit reverts r176036.  Now that we're correctly parsing the intel
syntax the pushad/popad don't match properly.  I've reimplemented that fix using
a MnemonicAlias.

llvm-svn: 181620

llvm-svn: 181618

rdar://13854369 and PR15944

llvm-svn: 181564

We generate a `push' of a random register (%rax) if the stack needs to be
aligned by the size of that register. However, this could mess up compact unwind
generation. In particular, we want to still generate compact unwind in the
presence of this monstrosity.

Check if the push of of the %rax/%eax register. If it is and it's marked with
the `FrameSetup' flag, then we can generate a compact unwind encoding for the
function only if the push is the last FrameSetup instruction.

llvm-svn: 181540

The compact unwind registers were defined in two different
places. It's better just to place them in the function that uses them
and specify that this is a 64-bit or 32-bit machine.

No functionality change.

llvm-svn: 181529

llvm-svn: 181346

llvm-svn: 181313

X86ISelLowering has support to treat:
(icmp ne (and (xor %flags, -1), (shl 1, flag)), 0)

as if it were actually:
(icmp eq (and %flags, (shl 1, flag)), 0)

However, r179386 has code at the InstCombine level to handle this.

llvm-svn: 181145

Patch by Robert Wilhelm.

llvm-svn: 181138

llvm-svn: 181137

llvm-svn: 181136

llvm-svn: 181005

llvm-svn: 180992

llvm-svn: 180991

the "identifier" parsed by the frontend callback by skipping forward
until we've consumed a token that ends at the point dictated by the
callback.

In addition, inform the callback when it's parsing an unevaluated
operand (e.g. mov eax, LENGTH A::x) as opposed to an evaluated one
(e.g. mov eax, [A::x]).

This commit depends on a clang commit.

llvm-svn: 180978

llvm-svn: 180915

No functionality change

llvm-svn: 180914

No functionality change

llvm-svn: 180912

Patch by Joshua Magee.

llvm-svn: 180842

llvm-svn: 180600

Expunge all remaining traces and use of live variable information.

llvm-svn: 180577

latency for certain models of the Intel Atom family, by converting
instructions into their equivalent LEA instructions, when it is both
useful and possible to do so.

llvm-svn: 180573

Patch by Kai Nacke. This matches the gnu as output.

llvm-svn: 180568

Disp will always be one of MCSymbolRefExpr or MCConstantExpr, and never NULL.

llvm-svn: 180059

the MCParsedAsmOperand.
Part of rdar://13663589

llvm-svn: 180054

llvm-svn: 180044

now taken care of by the frontend, which allows us to parse arbitrary C/C++
variables.
Part of rdar://13663589

llvm-svn: 180037

change indended.
Part of rdar://13663589

llvm-svn: 180028

I think it's almost impossible to fold atomic fences profitably under
LLVM/C++11 semantics. As a result, this is now unused and just
cluttering up the target interface.

llvm-svn: 179940

llvm-svn: 179939

trying to move as much FastISel logic as possible out of the main path in
SelectionDAGISel - intermixing them just adds confusion.

llvm-svn: 179902

llvm-svn: 179901

llvm-svn: 179875

indended.
Part of rdar://13663589

llvm-svn: 179871

qualifiers don't necessarily begin with an identifier (e.g., ::foo::bar).

llvm-svn: 179867

llvm-svn: 179866

llvm-svn: 179865

llvm-svn: 179856

llvm-svn: 179833

llvm-svn: 179820