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

llvm-svn: 225945

Copy the `GVMap` over to a standard `ValueToValueMapTy` so that we can
reuse the `MapMetadata()` logic.  Unfortunately the `GVMap` can't just
be replaced, since `MapMetadata()` likes to modify the map, but at least
this will prevent NVPTX from bitrotting.

llvm-svn: 225944

The comment is incorrect, and the code mangles debug info.  Remove the
bad logic, which wasn't tested anyway.

llvm-svn: 225943

llvm-svn: 225942

The int instruction takes as an operand an 8-bit immediate value.  Validate that
the input is valid rather than silently truncating the value.

llvm-svn: 225941

Disable a couple of tests, CodeGen/X86/noop-insert.ll and CodeGen/X86/noop-insert-percentage.ll, in r225908, to unbreak tests.

llvm-svn: 225940

class members are implicitly "inline", no key word needed.

Naturally, this could change how LLVM inlines these functions because
<GRR>, but that's not an excuse to use the keyword. ;]

llvm-svn: 225939

significantly. Clean it up with the help of clang-format.

I've touched this up by hand in a couple of places that weren't quite
right (IMO). I think most of these actually have bugs open about
already.

llvm-svn: 225938

formatted or placed incorrectly.

llvm-svn: 225937

Correct, we have *zero* basic testing of the dominator tree in the
regression test suite. There is a single test that even prints it out,
and that test only checks a single line of the output. There are
a handful of tests that check post dominators, but all of those are
looking for bugs rather than just exercising the basic machinery.

This test is super boring and unexciting. But hey, it's something.
I needed there to be something so I could switch the basic test to run
with both the old and new pass manager.

llvm-svn: 225936

  I.E. more than two -> exactly two
Fix a typo function name in LoopVectorize.
  I.E. collectStrideAcccess() -> collectStrideAccess()

llvm-svn: 225935

We would check the type information from the declaration found by lookup
but we would neglect checking compatibility with the most recent
declaration.  This would make it possible for us to not correctly
diagnose inconsistencies with declarations which were made in a
different scope.

llvm-svn: 225934

llvm-svn: 225933

llvm-svn: 225932

complain that the flag doesn't exist.

llvm-svn: 225931

Somehow we seem to have ended up without any actual tests of the
CodeGen side. Easy enough to fix.

llvm-svn: 225930

llvm-svn: 225929

The form of nops used is CPU-specific (some CPUs, such as the POWER7, have
special group-terminating nops). We probably want a different callback for this
kind of nop insertion (something more like MCAsmBackend::writeNopData), or for
PPC to use a different mechanism for scheduling nops, but this will stop the
test from failing for now.

llvm-svn: 225928

This reduces coverage for Evergreen, since the more
complete tests have those run lines disabled.

llvm-svn: 225927

Don't do the v4i8 -> v4f32 combine if the load will need to
be expanded due to alignment. This stops adding instructions
to repack into a single register that the v_cvt_ubyteN_f32
instructions read.

llvm-svn: 225926

Now that the source and destination types can be specified,
allow doing an expansion that doesn't use an EXTLOAD of the
result type. Try to do a legal extload to an intermediate type
and extend that if possible.

This generalizes the special case custom lowering of extloads
R600 has been using to work around this problem.

This also happens to fix a bug that would incorrectly use more
aligned loads than should be used.

llvm-svn: 225925

llvm-svn: 225924

Extend PipePosix with support for named pipes/timeout-based IO and integrate it with GDBRemoteCommunication / lldb-gdbserver - include reviews fixes.

http://reviews.llvm.org/D6954

llvm-svn: 225923

These are implemented with __builtin_shufflevector just like AVX.

We have some tests on the LLVM side to assert that these shufflevectors do
indeed generate the corresponding unpck instruction.

Part of <rdar://problem/17688758>

llvm-svn: 225922

Part of PR21433.

llvm-svn: 225921

llvm-svn: 225920

Should fix the bots after r225890.

llvm-svn: 225919

The new logic isn't actually reachable yet, so no functionality change.

llvm-svn: 225918

llvm-svn: 225917

llvm-svn: 225915

Still doesn't handle distinct ones.  Part of PR21433.

llvm-svn: 225914

The machine scheduler is still disabled by default.

The schedule model is not complete yet, and could be improved.

llvm-svn: 225913

llvm-svn: 225912

llvm-svn: 225911

A pass that adds random noops to X86 binaries to introduce diversity with the goal of increasing security against most return-oriented programming attacks.

Command line options:
  -noop-insertion // Enable noop insertion.
  -noop-insertion-percentage=X // X% of assembly instructions will have a noop prepended (default: 50%, requires -noop-insertion)
  -max-noops-per-instruction=X // Randomly generate X noops per instruction. ie. roll the dice X times with probability set above (default: 1). This doesn't guarantee X noop instructions.

In addition, the following 'quick switch' in clang enables basic diversity using default settings (currently: noop insertion and schedule randomization; it is intended to be extended in the future).
  -fdiversify

This is the clang part of the patch.
llvm part: D3392

http://reviews.llvm.org/D3393
Patch by Stephen Crane (@rinon)

llvm-svn: 225910

This re-applies r225808, fixed to avoid problems with SDAG dependencies along
with the preceding fix to ScheduleDAGSDNodes::RegDefIter::InitNodeNumDefs.
These problems caused the original regression tests to assert/segfault on many
(but not all) systems.

Original commit message:

This commit does two things:

 1. Refactors PPCFastISel to use more of the common infrastructure for call
    lowering (this lets us take advantage of this common code for lowering some
    common intrinsics, stackmap/patchpoint among them).

 2. Adds support for stackmap/patchpoint lowering. For the most part, this is
    very similar to the support in the AArch64 target, with the obvious differences
    (different registers, NOP instructions, etc.). The test cases are adapted
    from the AArch64 test cases.

One difference of note is that the patchpoint call sequence takes 24 bytes, so
you can't use less than that (on AArch64 you can go down to 16). Also, as noted
in the docs, we take the patchpoint address to be the actual code address
(assuming the call is local in the TOC-sharing sense), which should yield
higher performance than generating the full cross-DSO indirect-call sequence
and is likely just as useful for JITed code (if not, we'll change it).

StackMaps and Patchpoints are still marked as experimental, and so this support
is doubly experimental. So go ahead and experiment!

llvm-svn: 225909

A pass that adds random noops to X86 binaries to introduce diversity with the goal of increasing security against most return-oriented programming attacks.

Command line options:
  -noop-insertion // Enable noop insertion.
  -noop-insertion-percentage=X // X% of assembly instructions will have a noop prepended (default: 50%, requires -noop-insertion)
  -max-noops-per-instruction=X // Randomly generate X noops per instruction. ie. roll the dice X times with probability set above (default: 1). This doesn't guarantee X noop instructions.

In addition, the following 'quick switch' in clang enables basic diversity using default settings (currently: noop insertion and schedule randomization; it is intended to be extended in the future).
  -fdiversify

This is the llvm part of the patch.
clang part: D3393

http://reviews.llvm.org/D3392
Patch by Stephen Crane (@rinon)

llvm-svn: 225908

PATCHPOINT is a strange pseudo-instruction. Depending on how it is used, and
whether or not the AnyReg calling convention is being used, it might or might
not define a value. However, its TableGen definition says that it defines one
value, and so when it doesn't, the code in ScheduleDAGSDNodes::RegDefIter
becomes confused and the code that uses the RegDefIter will try to get the
register class of the MVT::Other type associated with the PATCHPOINT's chain
result (under certain circumstances).

This will be covered by the PPC64 PatchPoint test cases once that support is
re-committed.

llvm-svn: 225907

llvm-svn: 225906

llvm-svn: 225905