operand list instead of the operand list redundantly declared on the alias
or instruction.

With this change, we finally remove the ins/outs list on the alias.  Before:
  def : InstAlias<(outs GR16:$dst), (ins GR8 :$src),
                  "movsx $src, $dst",
                  (MOVSX16rr8W GR16:$dst, GR8:$src)>;
After:
  def : InstAlias<"movsx $src, $dst",
                  (MOVSX16rr8W GR16:$dst, GR8:$src)>;

This also makes the alias mechanism more general and powerful, which will
be exploited in subsequent patches.

llvm-svn: 118329

llvm-svn: 118310

llvm-svn: 118309

llvm-svn: 118307

llvm-svn: 118304

llvm-svn: 118301

llvm-svn: 118300

llvm-svn: 118295

llvm-svn: 118294

llvm-svn: 118291

(relocations, e.g.), but this will allow simple things to flow through.

llvm-svn: 118289

llvm-svn: 118288

llvm-svn: 118287

llvm-svn: 118280

to perform the copy, which may be of lots of memory [*].  It would be good if the
fall-back code generated something reasonable, i.e. did the copy in a loop, rather
than vast numbers of loads and stores.  Add a note about this.  Currently target
specific code seems to always kick in so this is more of a theoretical issue rather
than a practical one now that X86 has been fixed.
[*] It's amazing how often people pass mega-byte long arrays by copy...

llvm-svn: 118275

llvm-svn: 118272

sequence of loads and stores was being generated to perform the
copy on the x86 targets if the parameter was less than 4 byte
aligned, causing llc to use up vast amounts of memory and time.
Use a "rep movs" form instead.  PR7170.

llvm-svn: 118260

llvm-svn: 118257

llvm-svn: 118254

they do :-(

llvm-svn: 118250

llvm-svn: 118249

Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.

To create debugging information for a pointer, using DIBUilder front-end just needs
	DBuilder.CreatePointerType(Ty, Size);
instead of
	DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
                                       TheCU, "", getOrCreateMainFile(),
                                       0, Size, 0, 0, 0, OCTy);

llvm-svn: 118248

and as such can be represented by an MVT - the more complicated
EVT is not needed.  Use MVT for ValVT everywhere.

llvm-svn: 118245

Fix @llvm.prefetch isel. Selecting between pld / pldw using the first immediate rw. There is currently no intrinsic that matches to pli.

llvm-svn: 118237

 - Primarily useful for running some code with a specified stack size, when
   pthreads are available.

llvm-svn: 118222

tweaking when we start using it for object file emission or JIT, but it's a
start.

llvm-svn: 118221

llvm-svn: 118220

This way, InlineSpiller does the same amount of splitting as the standard
spiller. Splitting should really be guided by the register allocator, and
doesn't belong in the spiller at all.

llvm-svn: 118216

CodeEmitter.

llvm-svn: 118209

This is both the conceptually correct place for it, as well as allowing it to be more aggressive.

llvm-svn: 118204

We could be more aggressive about making this work for a larger range of constants,
but this seems like a good start.

llvm-svn: 118201

llvm-svn: 118199

just do it earlier too.

llvm-svn: 118195

splitting needs them.

llvm-svn: 118194

llvm-svn: 118193

llvm-svn: 118192

all of the different element sizes are pseudo instructions that map down to vext.8 underneath, with
the immediate shifted left to reflect the increased element size.

llvm-svn: 118183

llvm-svn: 118176

For NEON we had been assuming this was always an immediate constant.

llvm-svn: 118175

Makes it more clear that it is just a path manipulation function.

llvm-svn: 118174