llvm-svn: 148662

Patch by Ana Pazos!

llvm-svn: 148658

llvm-svn: 148654

in a subclass named DyldELFObject. This class supports rebasing the object file
it represents by re-mapping section addresses to the actual memory addresses
the object was placed in. This is required for MC-JIT implementation on ELF with
debugging support.

Patch reviewed on llvm-commits.

Developed together with Ashok Thirumurthi and Andrew Kaylor.

llvm-svn: 148653

ELF and MachO implementations of RuntimeDyldImpl go into their own header files now.

Reviewed on llvm-commits

llvm-svn: 148652

llvm-svn: 148651

llvm-svn: 148644

llvm-svn: 148643

Add memory patterns for some of the fp<->integer conversion instructions. Fold some patterns into instruction definitions.

llvm-svn: 148641

llvm-svn: 148635

Fix PR11819 introduced by r148537. I'd commit the test case, but the generated code is terrible as it gets fully scalarized. Expect a future commit to fix that.

llvm-svn: 148632

llvm-svn: 148622

A register mask operand kills any live physreg that isn't preserved.
Unlike an implicit-def operand, the clobbered physregs are never live
afterwards.

This means LiveVariables has to track a much smaller number of live
physregs, and it should spend much less time in addRegisterDead().

llvm-svn: 148609

The MachO file stores section alignment as log2(alignment-in-bytes). The
allocation routines want the raw alignment-in-bytes value, so adjust
for that.

llvm-svn: 148604

llvm-svn: 148601

llvm-svn: 148594

llvm-svn: 148593

llvm-svn: 148591

Only PostRA LICM is affected.

llvm-svn: 148589

Don't track live physregs that are clobbered by a register mask operand.

llvm-svn: 148588

llvm-svn: 148578

Fixes PR11783: bad cast to AddRecExpr.

llvm-svn: 148572

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

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

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

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

'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: 148495

llvm-svn: 148493