llvm-svn: 189195

llvm-svn: 189189

a non-constant GEP.

I don't have any test case that demonstrates this, Nadav (indirectly)
pointed this out in code review. I'm not sure how possible it is to
contrive a test case for the current users of this code that triggers
the bad issue sadly.

llvm-svn: 189188

We currently emit labels with the prefix Lllvm$workaround$fake$stub$ if
the target's MCAsmInfo has getLinkOnceDirective() mapped to something
interesting.  This was apparently a work around introduced in r31033 for
binutils that we don't need anymore.

llvm-svn: 189187

I need to add the rest of these to the list or else to delay putting
out the actual stub until later in code generation when I know if
the external function ever got emitted

Resubmit this patch. The target triple needs to be added to the test so that 
clang does not tell the backend the wrong target when the host is BSD. There
is a clang bug in here somewhere that I need to track down. At Mips this
has been filed internally as a bug.

llvm-svn: 189186

Add hasSideEffects/mayLoad/mayStore flags to the X86 moffs8/moffs16/moffs32/moffs64 versions of move.

llvm-svn: 189182

llvm-svn: 189179

llvm-svn: 189178

llvm-svn: 189176

llvm-svn: 189173

Replace instances of this scattered around the code base.

llvm-svn: 189169

llvm-svn: 189168

Leak found by valgrind.

llvm-svn: 189167

Patch by Ismail Pazarbasi.

llvm-svn: 189162

I need to add the rest of these to the list or else to delay putting
out the actual stub until later in code generation when I know if
the external function ever got emitted.

llvm-svn: 189161

This support was removed by accident during the MC conversion

llvm-svn: 189160

llvm-svn: 189158

There is no advantage in being different and using the same names simplifies
clang a bit.

llvm-svn: 189141

llvm-svn: 189133

llvm-svn: 189131

llvm-svn: 189124

llvm-svn: 189123

llvm-svn: 189122

llvm-svn: 189121

Estimate the cyclic critical path within a single block loop. If the
acyclic critical path is longer, then the loop will exhaust OOO
resources after some number of iterations. If lag between the acyclic
critical path and cyclic critical path is longer the the time it takes
to issue those loop iterations, then aggressively schedule for
latency.

llvm-svn: 189120

This will be used to compute the cyclic critical path and to
update precomputed per-node pressure differences.
In the longer term, it could also be used to speed up LiveInterval
update by avoiding visiting all global vreg users.

llvm-svn: 189118

This fixes a pathological compile time problem with very large blocks
and lots of scheduling boundaries.

llvm-svn: 189116

llvm-svn: 189111

llvm-svn: 189109

The code was erroneously reading overflow area shadow from the TLS slot,
bypassing the local copy. Reading shadow directly from TLS is wrong, because
it can be overwritten by a nested vararg call, if that happens before va_start.

llvm-svn: 189104

llvm-svn: 189103

This function attribute indicates that the function is not optimized
by any optimization or code generator passes with the 
exception of interprocedural optimization passes.

llvm-svn: 189101

Just the instructions and intrinsics for now.

llvm-svn: 189100

This allows us to make more use of the many compare reg,mem instructions.

llvm-svn: 189099

If we had a store of an integer to memory, and the integer and store size
were suitable for a form of MV..., we used MV... no matter what.  We could
then have sequences like:

    lay %r2, 0(%r3,%r4)
    mvi 0(%r2), 4

In these cases it seems better to force the constant into a register
and use a normal store:

    lhi %r2, 4
    stc %r2, 0(%r3, %r4)

since %r2 is more likely to be hoisted and is easier to rematerialize.

llvm-svn: 189098

...so that it can be used for z too.  Most of the code is the same.
The only real change is to use TargetTransformInfo to test when a sqrt
instruction is available.

The pass is opt-in because at the moment it only handles sqrt.

llvm-svn: 189097

I'd forgotten that "Requires" blocks override rather than add to the
constraints, so my pseudo-instruction was being selected in Thumb mode leading
to nonsense instructions.

rdar://problem/14817358

llvm-svn: 189096

llvm-svn: 189095

llvm-svn: 189091

Summary:
This is a part of D1164. DWARFCompileUnit is not that lightweight
to copy it around, and we want it to own corresponding .dwo compile unit
eventually.

Reviewers: echristo

Reviewed By: echristo

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1298

llvm-svn: 189089