definition for it. In that case, we want to wait for the potential definition
before we create a symbol for it.

llvm-svn: 153859

dependent contexts.

llvm-svn: 153858

llvm-svn: 153857

This is an initial commit of constexpr support as proposed by Richard Smith.  This by no means completes constexpr support.  Indeed, it hardly scratches the surface.  All it does is lay the foundation in <__config> and changes those few places in the library that are already using that foundation.

llvm-svn: 153856

I believe tuple is still under development in the standard.  Daniel Krugler is/will be making convincing arguments that a modified form of LWG 2051 (currently NAD Future) is easily acheivable and desirable.  He has demonstrated that a tuple<T...> where all of the T are implicitly convertible from U... should have a tuple constructor that is also implicit, instead of explicit.  This would support the use cases in LWG 2051 while not undermining T... with explicit conversions from U....  This check-in is an experimental implementation of Daniel's work.  I believe this work to be mature enough to warrant inclusion into libc++.  If anyone sees real-world problems that this check in causes, please let me know and I will revert it, and provide the feedback to the LWG.

llvm-svn: 153855

llvm-gcc doesn't handle --serialize-diagnostics so when compiling i386
kernel/kext code with -Werror, you get an error about that option being
unused.  Claim the argument to prevent this from breaking builds.
<rdar://problem/11161933>

llvm-svn: 153854

rather than a bitfield, a great suggestion by Chris during code review.

There is still quite a bit of cruft in the interface, but that requires
sorting out some awkward uses of the cost inside the actual inliner.

No functionality changed intended here.

llvm-svn: 153853

llvm-svn: 153852

llvm-svn: 153851

llvm-svn: 153850

llvm-svn: 153849

1. Simplify xor/and/or (bitcast(A), bitcast(B)) -> bitcast(op (A,B))
   (and also scalar_to_vector).

2. Xor/and/or are indifferent to the swizzle operation (shuffle of one src).
   Simplify xor/and/or (shuff(A), shuff(B)) -> shuff(op (A, B))

3. Optimize swizzles of shuffles:  shuff(shuff(x, y), undef) -> shuff(x, y).

4. Fix an X86ISelLowering optimization which was very bitcast-sensitive.

Code which was previously compiled to this:

movd    (%rsi), %xmm0
movdqa  .LCPI0_0(%rip), %xmm2
pshufb  %xmm2, %xmm0
movd    (%rdi), %xmm1
pshufb  %xmm2, %xmm1
pxor    %xmm0, %xmm1
pshufb  .LCPI0_1(%rip), %xmm1
movd    %xmm1, (%rdi)
ret

Now compiles to this:

movl    (%rsi), %eax
xorl    %eax, (%rdi)
ret

llvm-svn: 153848

Analyzer: Store BugReports directly in a ilist instead of adding another layer of inderection with std::list

llvm-svn: 153847

llvm-svn: 153846

The 440 and A2 cores have detailed itineraries, and this allows them to be
fully used to maximize throughput.

llvm-svn: 153845

llvm-svn: 153844

Post-RA scheduling gives a significant performance improvement on
the embedded cores, so turn it on. Using full anti-dep. breaking is
important for FP-intensive blocks, so turn it on (just on the
embedded cores for now; this should also be good on the 970s because
post-ra scheduling is all that we have for now, but that should have
more testing first).

llvm-svn: 153843

This adds a full itinerary for IBM's PPC64 A2 embedded core. These
cores form the basis for the CPUs in the new IBM BG/Q supercomputer.

llvm-svn: 153842

Use SequenceToOffsetTable to create instruction name table. Saves space particularly on X86 where AVX instructions just add a 'v' to the front of other instructions.

llvm-svn: 153841

llvm-svn: 153840

llvm-svn: 153839

When deriving new values for the statements of a SCoP, we assumed that parameter
values are constant within the SCoP and consquently do not need to be rewritten.
For OpenMP code generation this assumption is wrong, as such values are not
available in the OpenMP subfunction and consequently also may need to be
rewritten.

Committed with some changes.

Contributed-By: Johannes Doerfert <s9jodoer@stud.uni-saarland.de>
llvm-svn: 153838

This also avoids emitting the information twice, which led to code bloat. On i386-linux-Release+Asserts
with all targets built this change shaves a whopping 1.3 MB off clang. The number is probably exaggerated
by recent inliner changes but the methods were already enormous with the old inline cost computation.

The DWARF reg -> LLVM reg mapping doesn't seem to have holes in it, so it could be a simple lookup table.
I didn't implement that optimization yet to avoid potentially changing functionality.

There is still some duplication both in tablegen and the generated code that should be cleaned up eventually.

llvm-svn: 153837

As a side note, I really dislike array_pod_sort... Do we really still
care about any STL implementations that get this so wrong? Does libc++?

llvm-svn: 153834

always-inlining is disabled: recursive functions and indirectbr.

llvm-svn: 153833

a single missing character. Somehow, this had gone untested. I've added
tests for returns-twice logic specifically with the always-inliner that
would have caught this, and fixed the bug.

Thanks to Matt for the careful review and spotting this!!! =D

llvm-svn: 153832

test and FileCheck.

llvm-svn: 153831

llvm-svn: 153827

llvm-svn: 153825

llvm-svn: 153823

JIT that enables paired relocations in the i386
Mach-O JIT.  This eliminates crashes in the
testsuite when running under i386.

llvm-svn: 153822

Loads and stores can have different pipeline behavior, especially on
embedded chips. This change allows those differences to be expressed.
Except for the 440 scheduler, there are no functionality changes.
On the 440, the latency adjustment is only by one cycle, and so this
probably does not affect much. Nevertheless, it will make a larger
difference in the future and this removes a FIXME from the 440 itin.

llvm-svn: 153821

llvm-svn: 153820

llvm-svn: 153819

llvm-svn: 153818

This is the CodeGen equivalent of r153747. I tested that there is not noticeable
performance difference with any combination of -O0/-O2 /-g when compiling
gcc as a single compilation unit.

llvm-svn: 153817

Dynamic linking on PPC64 has had problems since we had to move the top-down
hazard-detection logic post-ra. For dynamic linking to work there needs to be
a nop placed after every call. It turns out that it is really hard to guarantee
that nothing will be placed in between the call (bl) and the nop during post-ra
scheduling. Previous attempts at fixing this by placing logic inside the
hazard detector only partially worked.

This is now fixed in a different way: call+nop codegen-only instructions. As far
as CodeGen is concerned the pair is now a single instruction and cannot be split.
This solution works much better than previous attempts.

The scoreboard hazard detector is also renamed to be more generic, there is currently
no cpu-specific logic in it.

llvm-svn: 153816

llvm-svn: 153815

the very high overhead of the complex inline cost analysis when all it
wants to do is detect three patterns which must not be inlined. Comment
the code, clean it up, and leave some hints about possible performance
improvements if this ever shows up on a profile.

Moving this off of the (now more expensive) inline cost analysis is
particularly important because we have to run this inliner even at -O0.

llvm-svn: 153814

interfaces. These methods were used in the old inline cost system where
there was a persistent cache that had to be updated, invalidated, and
cleared. We're now doing more direct computations that don't require
this intricate dance. Even if we resume some level of caching, it would
almost certainly have a simpler and more narrow interface than this.

llvm-svn: 153813