Patch by Zoran Jovanovic.

llvm-svn: 180238

Fixes test/CodeGen/R600/setcc.ll

llvm-svn: 180231

The libelf implementation that is distributed here:
http://www.mr511.de/software/english.html
will not parse sections that are marked SHT_NULL.

llvm-svn: 180230

Patch by Filip Pizlo

llvm-svn: 180229

Fixes PR15838. Need to check for blocks with nothing but dbg.value.

I'm not sure how to force this situation with a unit test. I tried to
reduce the test case in PR15838 (1k lines of metadata) but gave up.

llvm-svn: 180227

rdar://13731657

llvm-svn: 180226

llvm-svn: 180225

[objc-arc] Added ImpreciseAutoreleaseSet to track autorelease calls that were once autoreleaseRV instructions.

Due to the semantics of ARC, we must be extremely conservative with autorelease
calls inserted by the frontend since ARC gaurantees that said object will be in
the autorelease pool after that point, an optimization invariant that the
optimizer must respect.

On the other hand, we are allowed significantly more flexibility with
autoreleaseRV instructions.

Often times though this flexibility is disrupted by early transformations which
transform objc_autoreleaseRV => objc_autorelease if said instruction is no
longer being used as part of an RV pair (generally due to inlining). Since we
can not tell the difference in between an autorelease put into place by the
frontend and one created through said ``strength reduction'' we can not perform
these optimizations.

The addition of this set gets around said issues by allowing us to differentiate
in between said two cases.

rdar://problem/13697741.

llvm-svn: 180222

llvm-svn: 180221

While here, don't report a dummy symbol for relocations that don't have symbols.
We used to says such relocations were for the first defined symbol, but now we
return end_symbols(). The llvm-readobj output change agrees with otool.

llvm-svn: 180214

This makes it easier to read the code.

No functionality change.

llvm-svn: 180197

This patch disables memory-instruction vectorization for types that need padding
bytes, e.g., x86_fp80 has 10 bytes store size with 6 bytes padding in darwin on
x86_64. Because the load/store vectorization is performed by the bit casting to
a packed vector, which has incompatible memory layout due to the lack of padding
bytes, the present vectorizer produces inconsistent result for memory
instructions of those types.
This patch checks an equality of the AllocSize of a scalar type and allocated
size for each vector element, to ensure that there is no padding bytes and the
array can be read/written using vector operations.

Patch by Daisuke Takahashi!

Fixes PR15758.

llvm-svn: 180196

llvm-svn: 180195

This should bring the ppc bots back. I will try to write a test that would
have found the problem on a little endian system too.

llvm-svn: 180194

For now, we just reschedule instructions that use the copied vregs and
let regalloc elliminate it. I would really like to eliminate the
copies on-the-fly during scheduling, but we need a complete
implementation of repairIntervalsInRange() first.

The general strategy is for the register coalescer to eliminate as
many global copies as possible and shrink live ranges to be
extended-basic-block local. The coalescer should not have to worry
about resolving local copies (e.g. it shouldn't attemp to reorder
instructions). The scheduler is a much better place to deal with local
interference. The coalescer side of this equation needs work.

llvm-svn: 180193

When MachineScheduler is enabled, this functionality can be
removed. Until then, provide a way to disable it for test cases and
designing MachineScheduler heuristics.

llvm-svn: 180192

llvm-svn: 180191

llvm-svn: 180190

Since the relocation iterator walks only the relocations in one section, we
can just use a pointer and avoid fetching information about the section at
every reference.

llvm-svn: 180189

llvm-svn: 180186

I know what would be cool! We should align the compact unwind section because
aligned data access is faster.
<rdar://problem/13723271>

llvm-svn: 180171

Patch by Tom Stellard. (Committed while he's afk per request)

llvm-svn: 180157

llvm-svn: 180146

llvm-svn: 180145

No functionality change.

llvm-svn: 180144

debug location. This solves a problem where range of an inlined
subroutine is emitted wrongly.
Patch by Manman Ren.

Fixes rdar://problem/12415623

llvm-svn: 180140

Add more tests for r179925 to verify correct handling of signext/zeroext; strengthen condition check to require actual MVT::i32 virtual register types, just in case (no actual functionality change)

llvm-svn: 180138

llvm-svn: 180136

llvm-svn: 180133

No functional change intended.

llvm-svn: 180131

No intended changes in functionality.

llvm-svn: 180130

DAGCombine should not aggressively fold SEXT(VSETCC(...)) into a wider VSETCC without first checking the target's vector boolean contents.
This exposed an issue with PowerPC AltiVec where it appears it was setting the wrong vector boolean contents.  The included change
fixes the PowerPC tests, and was OK'd by Hal.

llvm-svn: 180129

Testing for _XCR_XFEATURE_ENABLED_MASK instead of a specific MSVC version because some MSVC 2010 SP1 installations do not have the _xgetbv intrinsic.  Patch thanks to Serge Pavlov!

llvm-svn: 180125

llvm-svn: 180124

llvm-svn: 180123

LoopVectorizer: Fix 15830. When scalarizing and unrolling stores make sure that the order in which the elements are scalarized is the same as the original order.
This fixes a miscompilation in FreeBSD's regex library.

llvm-svn: 180121

for absolute/absolute-set addressing modes.

llvm-svn: 180120

Made the uniform write test's checks a bit stricter.

llvm-svn: 180119

1) Disallow 'returned' on parameter that is also 'sret' (no sensible semantics, as far as I can tell).
2) Conservatively disallow tail calls through 'returned' parameters that also are 'zext' or 'sext' (for consistency with treatment of other zero-extending and sign-extending operations in tail call position detection...can be revised later to handle situations that can be determined to be safe).

This is a new attribute that is not yet used, so there is no impact.

llvm-svn: 180118

llvm-svn: 180112