llvm-svn: 148578

Fixes PR11783: bad cast to AddRecExpr.

llvm-svn: 148572

llvm-svn: 148571

llvm-svn: 148570

llvm-svn: 148569

We have patterns for vector sext and zext operations but were missing
anyext.  Without those patterns, codegen will fail when the selection DAG
has any_extend nodes.

llvm-svn: 148568

Providing a template argment to a non-templatized class was crashing
tblgen. Add a diagnostic.

For example,
$ cat bug.td
class A;

def B : A<0> {
}
$ llvm-tblgen bug.td
bug.td:3:11: error: template argument provided to non-template class
def B : A<0> {
          ^

llvm-svn: 148565

rdar://10724489

llvm-svn: 148560

For bit patterns that aren't representable using the 8-bit floating point
representation for vmov.f32, but are representable via vmov.i32, treat
the .f32 syntax as an alias. Most importantly, this covers the case
'vmov.f32 Vd, #0.0'.

rdar://10616677

llvm-svn: 148556

llvm-svn: 148555

Problem: LLVM needs more function attributes than currently available (32 bits).
One such proposed attribute is "address_safety", which shows that a function is being checked for address safety (by AddressSanitizer, SAFECode, etc).

Solution:
- extend the Attributes from 32 bits to 64-bits
- wrap the object into a class so that unsigned is never erroneously used instead
- change "unsigned" to "Attributes" throughout the code, including one place in clang.
- the class has no "operator uint64 ()", but it has "uint64_t Raw() " to support packing/unpacking.
- the class has "safe operator bool()" to support the common idiom:  if (Attributes attr = getAttrs()) useAttrs(attr);
- The CTOR from uint64_t is marked explicit, so I had to add a few explicit CTOR calls
- Add the new attribute "address_safety". Doing it in the same commit to check that attributes beyond first 32 bits actually work.
- Some of the functions from the Attribute namespace are worth moving inside the class, but I'd prefer to have it as a separate commit.

Tested:
"make check" on Linux (32-bit and 64-bit) and Mac (10.6)
built/run spec CPU 2006 on Linux with clang -O2.


This change will break clang build in lib/CodeGen/CGCall.cpp.
The following patch will fix it.

llvm-svn: 148553

llvm-svn: 148550

Found by the clang static analyzer.

llvm-svn: 148543

Found by the clang static analyzer.

llvm-svn: 148541

Found by the clang static analyzer.

llvm-svn: 148540

warnings from gcc.

llvm-svn: 148539

Improve 256-bit shuffle splitting to allow 2 sources in each 128-bit lane. As long as only a single lane of the source is used in the lane in the destination. This makes the splitting match much closer to what happens with 256-bit shuffles when AVX is disabled and only 128-bit XMM is allowed.

llvm-svn: 148537

can't handle. Also don't produce non-zero results for things which won't be
transformed by SROA at all just because we saw the loads/stores before we saw
the use of the address.

llvm-svn: 148536

LSR has gradually been improved to more aggressively reuse existing code, particularly existing phi cycles. This exposed problems with the SCEVExpander's sloppy treatment of its insertion point. I applied some rigor to the insertion point problem that will hopefully avoid an endless bug cycle in this area. Changes:

- Always used properlyDominates to check safe code hoisting.

- The insertion point provided to SCEV is now considered a lower bound. This is usually a block terminator or the use itself. Under no cirumstance may SCEVExpander insert below this point.

- LSR is reponsible for finding a "canonical" insertion point across expansion of different expressions.

- Robust logic to determine whether IV increments are in "expanded" form and/or can be safely hoisted above some insertion point.

Fixes PR11783: SCEVExpander assert.

llvm-svn: 148535

llvm-svn: 148532

Release+Asserts build with -DBUILD_SHARED_LIBS=ON, the install
directory goes from 72MB to 70MB.

llvm-svn: 148530

Remove a low-quality test which was failing on Windows; test/CodeGen/X86/sret.ll is a better test for the relevant behavior.

llvm-svn: 148526

'insertvalue' instructions that recreate the structure returned by the
'landingpad' instruction. Because the 'insertvalue' instruction isn't supported
by FastISel, this can save a bit of time during -O0 compilation.

llvm-svn: 148520

llvm-svn: 148513

llvm-svn: 148497

llvm-svn: 148495

llvm-svn: 148493

Add a new form of MCOperand, for representing sub-instructions.  This is intended for supporting bundles through the MC layer, rather than lowering them pre-MC as we currently do for Thumb2 IT blocks.  Since these sub-instruction operands hold pointers to the sub-instructions, it is the responsibility of the target's AsmPrinter to provide storage for them for the duration of the EmitInstruction() call.

llvm-svn: 148492

rdar://10531041.

llvm-svn: 148490

llvm-svn: 148489

llvm-svn: 148487

llvm-svn: 148486

llvm-svn: 148485

llvm-svn: 148473

llvm-svn: 148467

llvm-svn: 148466

llvm-svn: 148465

llvm-svn: 148464

T's that are consequtively in memory.

llvm-svn: 148463

llvm-svn: 148462