llvm-svn: 220377

It's not handling phis.

llvm-svn: 220371

This fails the verifier with:
"Expected a VCSrc_32 register, but got a VReg_1 register"

llvm-svn: 220368

llvm-svn: 220364

Thanks to Filipe Cabecinhas for the report.

llvm-svn: 220361

gcc's (4.7, I think) -Wcomment warning is not "as smart" as clang's and
warns even if the line right after the backslash-newline sequence only has
a line comment that starts at the beginning of the line.

llvm-svn: 220360

llvm-svn: 220357

llvm-svn: 220355

llvm-svn: 220354

llvm-svn: 220353

llvm-svn: 220352

ParamTLS (shadow for function arguments) is of limited size. This change
makes all arguments that do not fit unpoisoned, and avoids writing
past the end of a TLS buffer.

llvm-svn: 220351

This seems to have caused PR21330.

llvm-svn: 220349

On AArch64, GOT references are page relative (ADRP + LDR), so they can't be
applied until we know exactly where, within a page, the GOT entry will be in
the target address space.

Fixes <rdar://problem/18693976>.

llvm-svn: 220347

llvm-svn: 220346

Summary: Patches 202051 and 208013 added calls to LTO's PassManager which unconditionally add LoopVectorizePass and SLPVectorizerPass instead of following the logic in PassManagerBuilder::populateModulePassManager and honoring the -vectorize-loops -run-slp-after-loop-vectorization flags.

Reviewers: nadav, aschwaighofer, yijiang

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D5884

llvm-svn: 220345

llvm-svn: 220344

llvm-svn: 220342

These are named following the IEEE-754 names for these
functions, rather than the libm fmin / fmax to avoid
possible ambiguities. Some languages may implement something
resembling fmin / fmax which return NaN if either operand is
to propagate errors. These implement the IEEE-754 semantics
of returning the other operand if either is a NaN representing
missing data.

llvm-svn: 220341

Enumerate `MDNode`'s operands *before* the node itself, so that the
reader requires less RAUW.  Although this will cause different code
paths to be hit in the reader, this should effectively be no
functionality change.

llvm-svn: 220340

llvm-svn: 220338

No one cares how many uses each metadata value has, so don't bother
counting.

llvm-svn: 220337

This matches the behavior of GNU ar and also makes it easier to implemnt
support for the addlib command.

llvm-svn: 220336

llvm-svn: 220335

This is a micro optimization, but also makes the code a bit more flexible.

The MRIMembers variable is a short term hack. It is going away in the next
commit.

llvm-svn: 220334

This requires incorporating __GNUC_PATCHLEVEL__ into our prerequisite
check, and renaming our __GNUC_PREREQ to LLVM_GNUC_PREREQ, since it is
now functionally different.

Patch by Chilledheart!

Differential Revision: http://reviews.llvm.org/D5879

llvm-svn: 220332

The overridden one wasn't inserting a space,
so you would end up with .globalfoo

llvm-svn: 220329

llvm-svn: 220327

combineMetadata is used when merging two instructions into one.  This change teaches it how to merge 'nonnull' - i.e. only preserve it on the new instruction if it's set on both sources.  This isn't actually used yet since I haven't adjusted any of the call sites to pass in nonnull as a 'known metadata'.  

llvm-svn: 220325

When changing the type of a load in Chandler's recent InstCombine changes, we can preserve the new 'nonnull' metadata.  

I considered adding an assert since 'nonnull' is only valid on pointer types, but casting a pointer to a non-pointer would involve more than a bitcast anyways.  If someone extends this transform to handle more than bitcasts, the verifier will report the malformed IR, so a separate assertion isn't needed.  Also, the fpmath flags would have the same problem.

llvm-svn: 220324

The recently added !nonnull metadata is only valid on loads of pointer type.  

llvm-svn: 220323

This enables targets to adapt their pass pipeline to the register
allocator in use. For example, with the AArch64 backend, using PBQP
with the cortex-a57, the FPLoadBalancing pass is no longer necessary.

llvm-svn: 220321

llvm-svn: 220317

llvm-svn: 220316

This function was complicated by the fact that it tried to perform
canonicalizations that were already preformed by InstSimplify.  Remove
this extra code and move the tests over to InstSimplify.  Add asserts to
make sure our preconditions hold before we make any assumptions.

llvm-svn: 220314

llvm-svn: 220310

llvm-svn: 220309

llvm-svn: 220308

llvm-svn: 220304

It is just too easy to use a virtual register intead of a NodeId without a
compiler warning. This does not fix the fundamental problem, i.e. both
have the same underlying types, but increases the likelyhood to detect it.

llvm-svn: 220303