| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This speeds up the dependency calculations for blocks with many load/store/call instructions.
Beside the improved runtime, there is no functional change.
Compared to the original commit, this re-applied commit contains a bug fix which ensures that there are
no incorrect collisions in the alias cache.
llvm-svn: 225977
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
llvm-svn: 225974
 | 
| | 
| 
| 
|  | 
llvm-svn: 225972
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This adds the domtree analysis to the new pass manager. The analysis
returns the same DominatorTree result entity used by the old pass
manager and essentially all of the code is shared. We just have
different boilerplate for running and printing the analysis.
I've converted one test to run in both modes just to make sure this is
exercised while both are live in the tree.
llvm-svn: 225969
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This commit refines the pattern for the octeon seq/seqi/sne/snei instructions.
The target register is set to 0 or 1 according to the result of the comparison.
In C, this is something like
rd = (unsigned long)(rs == rt)
This commit adds a zext to bring the result to i64. With this change the
instruction is selected for this type of code. (gcc produces the same code for
the above C code.)
llvm-svn: 225968
 | 
| | 
| 
| 
|  | 
llvm-svn: 225957
 | 
| | 
| 
| 
| 
| 
|  | 
The buildbots got upset after r225941, this should hopefully fix things.
llvm-svn: 225954
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
This option takes the name of the basic block you want to visualize
with -view-*-dags
Differential Revision: http://reviews.llvm.org/D6948
llvm-svn: 225953
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
In case folding a node end up with a NaN as operand for the select, 
the folding of the condition of the selectcc node returns "UNDEF".
Differential Revision: http://reviews.llvm.org/D6889
llvm-svn: 225952
 | 
| | 
| 
| 
|  | 
llvm-svn: 225951
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
If there is no associated immediate (MS style inline asm), do not try to access
the operand, assume that it is valid.  This should fix the buildbots after SVN
r225941.
llvm-svn: 225950
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
When processing an array, every Elt has the same layout, it is
useless to recursively call each ComputeLinearIndex on each element.
Just do it once and multiply by the number of elements.
    
Differential Revision: http://reviews.llvm.org/D6832
llvm-svn: 225949
 | 
| | 
| 
| 
| 
| 
| 
|  | 
This reverts commit:
http://reviews.llvm.org/D3392
llvm-svn: 225948
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
I.E. more than two -> exactly two
Fix a typo function name in LoopVectorize.
  I.E. collectStrideAcccess() -> collectStrideAccess()
llvm-svn: 225935
 | 
| | 
| 
| 
|  | 
llvm-svn: 225929
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
Part of PR21433.
llvm-svn: 225921
 | 
| | 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This adds handling for ExceptionHandling::MSVC, used by the
x86_64-pc-windows-msvc triple. It assumes that filter functions have
already been outlined in either the frontend or the backend. Filter
functions are used in place of the landingpad catch clause type info
operands. In catch clause order, the first filter to return true will
catch the exception.
The C specific handler table expects the landing pad to be split into
one block per handler, but LLVM IR uses a single landing pad for all
possible unwind actions. This patch papers over the mismatch by
synthesizing single instruction BBs for every catch clause to fill in
the EH selector that the landing pad block expects.
Missing functionality:
- Accessing data in the parent frame from outlined filters
- Cleanups (from __finally) are unsupported, as they will require
  outlining and parent frame access
- Filter clauses are unsupported, as there's no clear analogue in SEH
In other words, this is the minimal set of changes needed to write IR to
catch arbitrary exceptions and resume normal execution.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D6300
llvm-svn: 225904
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Although this makes the `cast<>` assert more often, the
`assert(Node->isResolved())` on the following line would assert in all
those cases.  So, no functionality change here.
llvm-svn: 225903
 | 
| | 
| 
| 
|  | 
llvm-svn: 225902
 | 
| | 
| 
| 
|  | 
llvm-svn: 225901
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
DIEDwarfExpression (and get rid of a bunch of redundant code).
NFC
llvm-svn: 225900
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
status in a bool and let the users deal with the error.
NFC.
llvm-svn: 225899
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
needs to be accessed from both DwarfCompileUnit.cpp and DwarfUnit.cpp.
NFC.
llvm-svn: 225898
 | 
| | 
| 
| 
|  | 
llvm-svn: 225897
 | 
| | 
| 
| 
| 
| 
|  | 
Working towards supporting `MDLocation` in `MapMetadata()`.
llvm-svn: 225896
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
It turns out, all callsites of the simplifier are guarded by a check for
CallInst::getCalledFunction (i.e., to make sure the callee is direct).
This check wasn't done when trying to further optimize a simplified fortified
libcall, introduced by a refactoring in r225640.
Fix that, add a testcase, and document the requirement.
llvm-svn: 225895
 | 
| | 
| 
| 
|  | 
llvm-svn: 225893
 | 
| | 
| 
| 
| 
| 
|  | 
the TargetMachine level and the MC level.
llvm-svn: 225891
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
a print method.
This was formulated on a bad idea, but sadly I didn't uncover how bad
this was until I got further down the path. I had hoped that we could
provide a low boilerplate way of printing analyses, but it just doesn't
seem like this really fits the needs of the analyses. Not all analyses
really want to do printing, and those that do don't all use the same
interface. Instead, with the new pass manager let's just take advantage
of the fact that creating an explicit printer pass like the LCG has is
pretty low boilerplate already and rely on that for testing.
llvm-svn: 225861
 | 
| | 
| 
| 
| 
| 
|  | 
no frame register. "Tested" via an assertion triggered by DwarfExpression.
llvm-svn: 225858
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
This reverts commit r225852, it was a bad idea.
MachineReg should always be a physical register. If it isn't this DebugLoc
shouldn't have been created in the first place.
llvm-svn: 225857
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
I'm adding generic analysis printing utility pass support which will
require such a method (or a specialization) so this will let the
existing printing logic satisfy that.
llvm-svn: 225854
 |