This reverts r257221.

This caused several build bot failures

* It looks like some of the tests don't work correctly under Windows
* It looks like the lit per test timeout tests fail

So I'm reverting for now. Once the above failures are fixed running
lit's tests can be enabled again.

llvm-svn: 257268

Previously, all whitespace characters would increase the starting
column, which doesn't make sense. This fixes a problem, e.g. with the
length calculation in JS template strings.

llvm-svn: 257267

AVX1 v8i32/v4i64 shuffles are bitcasted to v8f32/v4f64, this patch peeks through any bitcast to check for a load node to allow broadcasts to occur.

This is a re-commit of r257055 after r257264 fixed 32-bit broadcast loads of i64 scalars.

llvm-svn: 257266

Previously the CompileOnDemand layer was hard-coded to use a new
SectionMemoryManager for each function when it was called.

llvm-svn: 257265

Added 32-bit AVX1/AVX2 broadcast tests.

llvm-svn: 257264

managers.

Prior to this patch, recursive finalization (where finalization of one
RuntimeDyld instance triggers finalization of another instance on which the
first depends) could trigger memory access failures: When the inner (dependent)
RuntimeDyld instance and its memory manager are finalized, memory allocated
(but not yet relocated) by the outer instance is locked, and relocation in the
outer instance fails with a memory access error.

This patch adds a latch to the RuntimeDyld::MemoryManager base class that is
checked by a new method: RuntimeDyld::finalizeWithMemoryManagerLocking, ensuring
that shared memory managers are only finalized by the outermost RuntimeDyld
instance.

This allows ORC clients to supply the same memory manager to multiple calls to
addModuleSet. In particular it enables the use of user-supplied memory managers
with the CompileOnDemandLayer which must reuse the supplied memory manager for
each function that is lazily compiled.

llvm-svn: 257263

No functionality change intended.

llvm-svn: 257262

No functional change intended.

llvm-svn: 257261

FixedCompilationDatabase sets the working dir to "." by default. For
chdir(".") this is a noop but this lead to InMemoryFileSystem to create
bogus paths. Fixes PR25327.

llvm-svn: 257260

llvm-svn: 257259

Starting here:
  int x; // Format this line only.
  int xx; //
  int xxxxx; //

Before:
  int x;     // Format this line only.
  int xx; //
  int xxxxx; //

After:
  int x;  // Format this line only.
  int xx; //
  int xxxxx; //

llvm-svn: 257258

Before:
  void aaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaa,
                          vector<int>
                              bbbbbbbbbbbbbbb);

After:
  void aaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaa,
                          vector<int> bbbbbbbbbbbbbbb);

llvm-svn: 257257

Before:
  bool operator, ();

After:
  bool operator,();

llvm-svn: 257256

Before:
  var x: {
    a: string;
    b: number;
  }
  = {};

After:
  var x: {a: string; b: number;} = {};

llvm-svn: 257255

Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441


Reviewers: pekka.jaaskelainen, Anastasia

Subscribers: bader, Anastasia, cfe-commits

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

llvm-svn: 257254

Merge MBBICommon and MBBI's MMOs.

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

llvm-svn: 257253

Fix a typo

llvm-svn: 257252

tag (because the previous declaration was found in a different module), inject
the tag into the appropriate scope (that is, the enclosing scope if we're in a
function prototype scope in C++).

llvm-svn: 257251

Summary:
This is analogous to r256079, which removed an overly strong assertion, and
r256812, which simplified the code by replacing three conditionals by one.

Reviewers: reames

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 257250

llvm-svn: 257249

[libFuzzer] change the way trace-based mutations are applied. Instead of a custom code just rely on the automatically created dictionary

llvm-svn: 257248

llvm-svn: 257247

llvm-svn: 257245

This patch teaches rewrite-statepoints-for-gc to relocate vector-of-pointers directly rather than trying to split them. This builds on the recent lowering/IR changes to allow vector typed gc.relocates.

The motivation for this is that we recently found a bug in the vector splitting code where depending on visit order, a vector might not be relocated at some safepoint. Specifically, the bug is that the splitting code wasn't updating the side tables (live vector) of other safepoints. As a result, a vector which was live at two safepoints might not be updated at one of them. However, if you happened to visit safepoints in post order over the dominator tree, everything worked correctly. Weirdly, it turns out that post order is actually an incredibly common order to visit instructions in in practice. Frustratingly, I have not managed to write a test case which actually hits this. I can only reproduce it in large IR files produced by actual applications.

Rather than continue to make this code more complicated, we can remove all of the complexity by just representing the relocation of the entire vector natively in the IR.

At the moment, the new functionality is hidden behind a flag. To use this code, you need to pass "-rs4gc-split-vector-values=0". Once I have a chance to stress test with this option and get feedback from other users, my plan is to flip the default and remove the original splitting code. I would just remove it now, but given the rareness of the bug, I figured it was better to leave it in place until the new approach has been stress tested.

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

llvm-svn: 257244

DLL export tables usually contain dllexport'ed symbol RVAs so that
applications which use the DLLs can find symbols from the DLLs.
However, there's a minor feature to "forward" DLL symbols to other
DLLs.

If you set an RVA to a string whose form is "<dllname>.<symbolname>"
(e.g. "KERNEL32.ExitProcess") instead of symbol RVA to the export
table, the loader interprets that as a forwarder symbol, and resolve
that symbol from the specified DLL.

This patch implements that feature.

llvm-svn: 257243

assuming a ValueObject always has a process.  So this is that fix
and the test case.

llvm-svn: 257242

llvm-svn: 257241

llvm-svn: 257240

[libFuzzer] refactor the way we collect cmp traces (don't use std::vector, don't limit with 8 bytes)

llvm-svn: 257239

llvm-svn: 257238

llvm-svn: 257237

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

llvm-svn: 257236

I prefer to use "-p" over using line_number and then setting by line because it's makes it possible
to see what the breakpoint is at the site where you make the breakpoint.  So I switched
it back to -p but specified the source file as well, which is an "all within lldb" way of doing
what Pavel's fix did.

llvm-svn: 257235

process in the incoming value be non-null, but Value Objects created off the target
don't necessarily have a process.  In that case, having the targets the same is good
enough.

<rdar://problem/24097805>

llvm-svn: 257234

The first argument is uint64_t, not uintptr_t.

llvm-svn: 257233

llvm-svn: 257232

-Wnull-conversion warning.

These functions are basically equivalent to other pointer returning fuctions
which are already excluded by -Wnull-conversion.

llvm-svn: 257231

IR level instrumentation needs to override version with variant bits.
No change for FE instrumentation is needed. Test case is added to
detect version mismatch.

llvm-svn: 257230

keys before we print the libdispatch queues keys (qname, qkind, qserialnum)
to make it easier to read the packet by hand.  No function difference, just
reordering the keys in the output.

llvm-svn: 257229

- fix buildbot breakage after r257186
- move declaration outside of for loop

llvm-svn: 257228