These types are not dependent in this context, so just look through
the sugar.

Review by Richard Smith & Eli Friedman.

llvm-svn: 186260

We also move the enum to UPPERCASE.

llvm-svn: 186259

Convert CodeGen/*/*.ll tests to use the new CHECK-LABEL for easier debugging. No functionality change and all tests pass after conversion.

This was done with the following sed invocation to catch label lines demarking function boundaries:
    sed -i '' "s/^;\( *\)\([A-Z0-9_]*\):\( *\)test\([A-Za-z0-9_-]*\):\( *\)$/;\1\2-LABEL:\3test\4:\5/g" test/CodeGen/*/*.ll
which was written conservatively to avoid false positives rather than false negatives. I scanned through all the changes and everything looks correct.

llvm-svn: 186258

This reverts commit b18b043a5a37f76803d89467e46bcac286c0ecae.

Reapply with fix for the configure+make build (missing include of
ASTContext.h).

llvm-svn: 186257

If an outside loop user of the reduction value uses the header phi node we
cannot just reduce the vectorized phi value in the vector code epilog because
we would loose VF-1 reductions.

lp:
  p = phi (0, lv)
  lv = lv + 1
  ...
  brcond , lp, outside

outside:
  usr = add 0, p

(Say the loop iterates two times, the value of p coming out of the loop is one).

We cannot just transform this to:

vlp:
  p = phi (<0,0>, lv)
  lv = lv + <1,1>
  ..
  brcond , lp, outside

outside:
  p_reduced = p[0] + [1];
  usr = add 0, p_reduced

(Because the original loop iterated two times the vectorized loop would iterate
one time, but p_reduced ends up being zero instead of one).

We would have to execute VF-1 iterations in the scalar remainder loop in such
cases. For now, just disable vectorization.

PR16522

llvm-svn: 186256

This reverts commit r186253.

This is failing to link under Configure+Make on the buildbots for
reasons I don't immediately understand.

llvm-svn: 186255

llvm-svn: 186254

Fix some uninstantiable code in ASTVector::insert. I've added a
cheap-and-dirty compile test for this, because I don't have the time to
figure out a nice way to get a real ASTContext to implement executable
tests - but we probably should have them for this ADT.

llvm-svn: 186253

between ELF (Linux, FreeBSD, NetBSD) and OSX as platform for the
assembler dialect.

llvm-svn: 186252

We make the option a clear choice between the two analysis types and add
descriptions about the difference between the two.

llvm-svn: 186251

llvm-svn: 186250

llvm-svn: 186249

llvm-svn: 186248

And .* did just match about anything anyways.

llvm-svn: 186246

It is failing with

YAMLTest.cpp:38:   instantiated from here
YAMLTraits.h:226: error: 'llvm::yaml::MappingTraits<<unnamed>::BinaryHolder>::mapping' is not a valid template argument for type 'void (*)(llvm::yaml::IO&, <unnamed>::BinaryHolder&)' because function 'static void llvm::yaml::MappingTraits<<unnamed>::BinaryHolder>::mapping(llvm::yaml::IO&, <unnamed>::BinaryHolder&)' has not external linkage

llvm-svn: 186245

llvm-svn: 186244

llvm-svn: 186243

llvm-svn: 186242

In general, one should always complete CFG modifications first, update
CFG-based analyses, like Dominatores and LoopInfo, then generate
instruction sequences.

LoopVectorizer was creating a new loop, calling SCEVExpander to
generate checks, then updating LoopInfo. I just changed the order.

llvm-svn: 186241

Looks like on mingw we get bogus last modification times on directories.
Should fix the mingw bots.

llvm-svn: 186240

llvm-svn: 186239

original message:
Fix a off by one error about which members need to use the string table.

llvm-svn: 186238

llvm-svn: 186237

decls. That can reenter deserialization and explode horribly by trying to merge
a declaration that we've not got very far through deserializing yet.

llvm-svn: 186236

llvm-svn: 186235

  http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-nobootstrap-RAincremental/builds/4328

Original commit log:
  Use the function attributes to pass along the stack protector buffer
  size.

llvm-svn: 186234

They don't seem to be used for back references, presumably because a
function template is unlikely to reoccur, while a class template name
may reoccur as a type.

This fixes a mangling issue for llvm::hash_combine() in Hashing.h.

Reviewers: timurrrr

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

llvm-svn: 186233

  http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/6897/steps/check-all/logs/LLVM%3A%3Aarchive-format.test

Original commit log:
  Fix a off by one error about which members need to use the string
  table.

llvm-svn: 186232

conforming protocols to each class. wip.

llvm-svn: 186231

llvm-svn: 186230

Fixes PR16605.

llvm-svn: 186229

write to registers if they were modified in the
expression.  This eliminates spurious errors if
the register can't be written to but the
expression didn't write to it anyway.

Also improved error handling for the materializer
to make "couldn't materialize struct" errors more
informative.

<rdar://problem/14322579>

llvm-svn: 186228

llvm-svn: 186227

ARM paired GPR COPY was being lowered to two MOVr without CC. This
patch puts the CC back.

My test is a reduction of the case where I encountered the issue,
64-bit atomics use paired GPRs.

The issue only occurs with selectionDAG, FastISel doesn't encounter it
so I didn't bother calling it.

llvm-svn: 186226

llvm-svn: 186225

undef vector of the wrong type.

LGTM'd by Nick Lewycky on IRC.

llvm-svn: 186224

RegisterContextCoreLinux_x86_64 inherits from RegisterContextLinux_x86_64 which inherits from RegisterContext_x86_64 which uses has:

   ProcessMonitor &GetMonitor();

This register context used by the core file can't use this since the process plug-in will be ProcessElfCore and the implementation of GetMonitor() does:

ProcessMonitor &
RegisterContext_x86_64::GetMonitor()
{
   ProcessSP base = CalculateProcess();
   ProcessPOSIX *process = static_cast<ProcessPOSIX*>(base.get());
   return process->GetMonitor();
}

ProcessELFCore doesn't, nor should it inherit from ProcessPOSIX and any call to GetMonitor() will fail for ELF core files.

Suggested cleanups:
- Make a register context class that is a base class that doesn't have any reading smarts, then make one that uses ProcessPOSIX and the has the GetMonitor() call, and one that gets its data straight from the core file. 

llvm-svn: 186223

llvm-svn: 186222

llvm-svn: 186221

protocols to classes. This is wip.

llvm-svn: 186220