llvm-svn: 137090

llvm-svn: 137067

These the methods are target-independent since they simply scan the
memory operands.  They can live in TargetInstrInfoImpl.

llvm-svn: 137063

X86FloatingPoint keeps track of pending ST registers for an upcoming
inline asm instruction with fixed stack register constraints.  It does
this by remembering which FP register holds the value that should appear
at a fixed stack position for the inline asm.

When that FP register is killed before the inline asm, make sure to
duplicate it to a scratch register, so the ST register still has a live
FP reference.

This could happen when the same FP register was copied to two ST
registers, or when a spill instruction is inserted between the ST copy
and the inline asm.

This fixes PR10602.

llvm-svn: 137050

llvm-svn: 136956

llvm-svn: 136954

llvm-svn: 136899

the PVS-studio tool.

llvm-svn: 136878

Move the reloc size assert into AsmBackend - where it is more apropos.

llvm-svn: 136855

Fixes PR10527.

llvm-svn: 136853

llvm-svn: 136803

This fixes PR10575.

llvm-svn: 136787

The testcase looks extremely fragile, so I'm adding an assertion which should catch any cases like this.

llvm-svn: 136711

  shuffle (scalar_to_vector (load (ptr + 4))), undef, <0, 0, 0, 0>
To:
  shuffle (vload ptr)), undef, <1, 1, 1, 1>
Fix PR10494

llvm-svn: 136691

Krasin!

llvm-svn: 136663

the legalizer. This commit together with the two previous ones fixes
PR10495.

llvm-svn: 136654

llvm-svn: 136653

using a stack store.

llvm-svn: 136652

avoid returning early for v8i32 types, which would only be valid for
vector with all zeros. Also split the handling of zeros and ones into separate
checking logic since they are handled differently. This fixes PR10547

llvm-svn: 136642

Update CMake target names for tablegen-generated data in the X86 and ARM targets. This should fix the CMake build with MSVC.

llvm-svn: 136621

working on x86 (at least for trivial testcases); other architectures will
need more work so that they actually emit the appropriate instructions for
orderings stricter than 'monotonic'. (As far as I can tell, the ARM, PPC,
Mips, and Alpha backends need such changes.)

llvm-svn: 136457

on the second half must be reindexed.

llvm-svn: 136454

generation to always catch the weird cases.

llvm-svn: 136453

llvm-svn: 136452

llvm-svn: 136451

undef mask elements. This fixes PR10529.

llvm-svn: 136450

Also tidy up code a bit.

llvm-svn: 136449

Also make PALIGNR masks to don't match 256-bits, which isn't supported
It's also a step to solve PR10489

llvm-svn: 136448

specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.

I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.

This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.

This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.

Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.

This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.

llvm-svn: 136433

LLVM*AsmPrinter.

GenLibDeps.pl fails to detect vtable references. As this is the only
referenced symbol from LLVM*Desc to LLVM*AsmPrinter on optimized
builds, the algorithm that creates the list of libraries to be linked
into tools doesn't know about the dependency and sometimes places the
libraries on the wrong order, yielding error messages like this:

../../lib/libLLVMARMDesc.a(ARMMCTargetDesc.cpp.o): In function
`llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo const&)':
ARMMCTargetDesc.cpp:(.text._ZN4llvm14ARMInstPrinterC1ERKNS_9MCAsmInfoE
[llvm::ARMInstPrinter::ARMInstPrinter(llvm::MCAsmInfo
const&)]+0x2a): undefined reference to `vtable for
llvm::ARMInstPrinter'

llvm-svn: 136328

llvm-svn: 136324

using vextractf128. This will reduce the number of issued instruction
for several avx codes.

llvm-svn: 136323

them to match 256-bit scalar_to_vector+zext.

llvm-svn: 136322

Take advantage that the 128-bit vpxor zeros the higher part and use it.
This also fixes PR10491

llvm-svn: 136321

a convert pattern close to the instruction definition.

llvm-svn: 136320

This can happen in cases where TableGen generated asm matcher cannot check
whether a register operand is in the right register class. e.g. mem operands.

rdar://8204588

llvm-svn: 136292

llvm-mc gives an "invalid operand" error for instructions that take an unsigned
immediate which have the high bit set such as:
    pblendw $0xc5, %xmm2, %xmm1
llvm-mc treats all x86 immediates as signed values and range checks them.
A small number of x86 instructions use the imm8 field as a set of bits.
This change only changes those instructions and where the high bit is not
ignored.  The others remain unchanged.

llvm-svn: 136287

llvm-svn: 136283

X86ISD::MEMBARRIER does not require SSE2; it doesn't actually generate any code, and all x86 processors will honor the required semantics.

llvm-svn: 136249

C++0x.

llvm-svn: 136211