llvm-svn: 134457

Add assembler/disassembler support for non-AVX pclmulqdq. While I'm here, use proper aliases for the pclmullqlqdq and friends. PR10269.

llvm-svn: 134424

If the function allocates reserved stack space for callee argument frames,
estimateStackSize() needs to account for that, as it doesn't show up as
ordinary frame objects. Otherwise, a callee with a large argument list will
throw off the calculations for whether to allocate an emergency spill slot
and we get assert() failures in the register scavenger.

rdar://9715469

llvm-svn: 134415

Noticed by Benjamin Kramer!

llvm-svn: 134376

This is what both the ABI and clang says.

llvm-svn: 134367

llvm-svn: 134323

llvm-svn: 134311

Add a MI->emitError() method that the backend can use to report errors
related to inline assembly. Call it from X86FloatingPoint.cpp when the
constraints are wrong.

This enables proper clang diagnostics from the backend:

$ clang -c pr30848.c
pr30848.c:5:12: error: Inline asm output regs must be last on the x87 stack
  __asm__ ("" : "=u" (d));  /* { dg-error "output regs" } */
           ^
1 error generated.

llvm-svn: 134307

up the valid constant check earlier.

rdar://9692967

llvm-svn: 134286

llvm-svn: 134281

llvm-svn: 134279

llvm-svn: 134264

The DSP instructions in the Thumb2 instruction set are an optional extension
in the Cortex-M* archtitecture. When present, the implementation is considered
an "ARMv7E-M implementation," and when not, an "ARMv7-M implementation."

Add a subtarget feature hook for the v7e-m instructions and hook it up. The
cortex-m3 cpu is an example of a v7m implementation, while the cortex-m4 is
a v7e-m implementation.

rdar://9572992

llvm-svn: 134261

llvm-svn: 134259

  itineraries.
- Refactor TargetSubtarget to be based on MCSubtargetInfo.
- Change tablegen generated subtarget info to initialize MCSubtargetInfo
  and hide more details from targets.

llvm-svn: 134257

(low two bits always zero, so off by one bit of encoded value).

llvm-svn: 134247

llvm-svn: 134244

t2MOVCC[ri] are just t2MOV[ri] instructions, so properly pseudo-ize them.
The Thumb1 versions, tMOVCC[ri] were only present for use by the size-
reduction pass, so they're no longer necessary at all and can be deleted.

llvm-svn: 134242

llvm-svn: 134224

supporting the instruction that the constraint is for 'movw'.

Part of rdar://9119939

llvm-svn: 134222

for the 'x' register constraint.

Part of rdar://9119939

llvm-svn: 134220

Part of rdar://9119939

llvm-svn: 134217

Part of rdar://9307836 and rdar://9119939

llvm-svn: 134215

llvm-svn: 134211

llvm-svn: 134210

llvm-svn: 134208

We would put the return value from long double functions in the wrong
register.

This fixes gcc.c-torture/execute/conversion.c

llvm-svn: 134205

Merge the tMOVr, tMOVgpr2tgpr, tMOVtgpr2gpr, and tMOVgpr2gpr instructions
into tMOVr. There's no need to keep them separate. Giving the tMOVr
instruction the proper GPR register class for its operands is sufficient
to give the register allocator enough information to do the right thing
directly.

llvm-svn: 134204

Part of rdar://9119939

llvm-svn: 134203

encoding for the registers it knows about. Return -1 if it can't handle that
register.

llvm-svn: 134202

No functional change.

Part of rdar://9119939

llvm-svn: 134198

Fix a FIXME and allow predication (in Thumb2) for the T1 register to
register MOV instructions. This allows some better codegen with
if-conversion (as seen in the test updates), plus it lays the groundwork
for pseudo-izing the tMOVCC instructions.

llvm-svn: 134197

llvm-svn: 134193

It's just a call to a special helper function. Get rid of the T2 variant
entirely, as it's identical to the Thumb1 version.

llvm-svn: 134178

It's just a t2LDMIA_UPD instruction with extra codegen properties, so it
doesn't need the encoding information. As a side-benefit, we now correctly
recognize for instruction printing as a 'pop' instruction.

llvm-svn: 134173

It's just a tPOP instruction with additional code-gen properties, so it
doesn't need encoding information.

llvm-svn: 134172

llvm-svn: 134131

tADDrSPi is not predicable, so we can't size-reduce a t2ADDri to it if the
predicate is anything other than "always."

llvm-svn: 134130

llvm-svn: 134129

be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.

The fix is to just have the clients explictly pass the CPU name!

llvm-svn: 134127