| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194553 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194549 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
This bug only bit the C++98 build bots because all of the actual uses
really do move. ;] But not *quite* ready to do the whole C++11 switch
yet, so clean it up. Also add a unit test that catches this immediately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194548 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194547 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch reapplies r193676 with an additional fix for the Hexagon backend. The
SystemZ backend has already been fixed by r194148.
The Type Legalizer recognizes that VSELECT needs to be split, because the type
is to wide for the given target. The same does not always apply to SETCC,
because less space is required to encode the result of a comparison. As a result
VSELECT is split and SETCC is unrolled into scalar comparisons.
This commit fixes the issue by checking for VSELECT-SETCC patterns in the DAG
Combiner. If a matching pattern is found, then the result mask of SETCC is
promoted to the expected vector mask type for the given target. Now the type
legalizer will split both VSELECT and SETCC.
This allows the following X86 DAG Combine code to sucessfully detect the MIN/MAX
pattern. This fixes PR16695, PR17002, and <rdar://problem/14594431>.
Reviewed by Nadav
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194542 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
pattern in use here. Addresses review feedback from Sean (thanks!) and
others.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194541 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
more smarts in it. This is where most of the interesting logic that used
to live in the implicit-scheduling-hackery of the old pass manager will
live.
Like the previous commits, note that this is a very early prototype!
I expect substantial changes before this is ready to use.
The core of the design is the following:
- We have an AnalysisManager which can be used across a series of
passes over a module.
- The code setting up a pass pipeline registers the analyses available
with the manager.
- Individual transform passes can check than an analysis manager
provides the analyses they require in order to fail-fast.
- There is *no* implicit registration or scheduling.
- Analysis passes are different from other passes: they produce an
analysis result that is cached and made available via the analysis
manager.
- Cached results are invalidated automatically by the pass managers.
- When a transform pass requests an analysis result, either the analysis
is run to produce the result or a cached result is provided.
There are a few aspects of this design that I *know* will change in
subsequent commits:
- Currently there is no "preservation" system, that needs to be added.
- All of the analysis management should move up to the analysis library.
- The analysis management needs to support at least SCC passes. Maybe
loop passes. Living in the analysis library will facilitate this.
- Need support for analyses which are *both* module and function passes.
- Need support for pro-actively running module analyses to have cached
results within a function pass manager.
- Need a clear design for "immutable" passes.
- Need support for requesting cached results when available and not
re-running the pass even if that would be necessary.
- Need more thorough testing of all of this infrastructure.
There are other aspects that I view as open questions I'm hoping to
resolve as I iterate a bit on the infrastructure, and especially as
I start writing actual passes against this.
- Should we have separate management layers for function, module, and
SCC analyses? I think "yes", but I'm not yet ready to switch the code.
Adding SCC support will likely resolve this definitively.
- How should the 'require' functionality work? Should *that* be the only
way to request results to ensure that passes always require things?
- How should preservation work?
- Probably some other things I'm forgetting. =]
Look forward to more patches in shorter order now that this is in place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194538 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194537 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
used, and HUGE_VALD does not appear to be supported everywhere anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194535 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
triggered in MSVC 12.
Patch reviewed by Reid Kleckner and Jim Grosbach.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194533 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194530 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
I still don't know how to refer to the fixed operands symbolically. I
plan to look into it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194529 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
print the name of the function on which the dependence analysis is performed
such that changes to the testcase are easier to review.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194528 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194527 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194526 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
that K1 and K2 are 'one-hot' (only one bit is on).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194525 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
the condition. It has a heuristics for estimating when some of the dependencies are processed by out-of-order processors. This patch adds another rule to the heuristics that says that if the "BonusInstruction" that we speculatively execute is used by the condition of the second branch then it is okay to hoist it. This change exposes more opportunities for other passes to transform the code. It does not matter that much that we if-convert the code because the selectiondag builder splits or/and branches into multiple branches when profitable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194524 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
argument was not being passed in $f14.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194522 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194519 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194515 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add user-supplied C runtime and compiler-rt library functions to
llvm.compiler.used to protect them from premature optimization by
passes like -globalopt and -ipsccp. Calls to (seemingly unused)
runtime library functions can be added by -instcombine and instruction
lowering.
Patch by Duncan Exon Smith, thanks!
Fixes <rdar://problem/14740087>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194514 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The system LDM and STM instructions can't usually writeback to the base
register. The one exception is when an LDM is actually an exception-return
(i.e. contains PC in the register list).
(There's already a test that "ldm sp!, {r0-r3, pc}^" works, which is why there
is no positive test).
rdar://problem/15223374
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194512 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194511 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194510 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
This commit significantly speeds up both bytecode and native
builds of LLVM clients (from ~20 second to sub-second link time),
and allows to invoke LLVM functions from OCaml toplevel.
The behavior for --disable-shared builds is unchanged.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194509 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194508 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Constant merge can merge a constant with implicit alignment with one that has
explicit alignment. Before this change it was assuming that the explicit
alignment was higher than the implicit one, causing the result to be under
aligned in some cases.
Fixes pr17815.
Patch by Chris Smowton!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194505 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
copy in MC layer. Added the MC layer tests. Fixed triple setting in test cases.
Patch by Ana Pazos <apazos@codeaurora.org>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194501 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194500 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already know how to fold a reload from a frameindex without
analyzing the load instruction. Generalize this to handle any
frameindex load. This streamlines the logic for rematerializing loads
from stack arguments. As a side effect, it allows stackmaps to record
a stack argument location without spilling it.
Verified no effect on codegen for llvm test-suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194497 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194496 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194495 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
This reverts commit r194485.
The variable is unused in some macro instantiations, but not others. We should
probably fix clang to not warn on this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194486 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194485 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194484 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like GCC, this re-uses the 'f' constraint and a new 'w' print-modifier:
asm ("ldi.w %w0, 1", "=f"(result));
Unlike GCC, the 'w' print-modifer is not _required_ to produce the intended
output. This is a consequence of differences in the internal handling of
the registers in each compiler. To be source-compatible between the
compilers, users must use the 'w' print-modifier.
MSA registers (including control registers) are supported in clobber lists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194476 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Both simpler and more powerful than the hand-rolled folding logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
assertions are disabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194472 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
not intrinsics)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194471 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194470 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
normal IR (i.e. not intrinsics)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194469 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(also xori to avoid bnegi)
Upcoming commit(s) are going to add support for bseti and bnegi. This would
cause some existing tests to (correctly) change behaviour and emit a different
instruction. This patch prevents this by changing the constant used in ori and
xori tests so that they will not be matchable by the bseti and bnegi patterns
when these instructions are matchable from normal IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194467 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194466 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
ATOMIC_FENCE is lowered to a compiler barrier which is codegen only. There
is no need to emit an instructions since the XCore provides sequential
consistency.
Original patch by Richard Osborne
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194464 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194463 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace std::map with SmallVector to memorize the cached result since SCEV usually belongs to little Loop/BB
Linear scan on SmallVector is faster than std::map.
Code reviewer : Andrew Trick.
Test result : Pass Unit Test & LLVM Test Suite
401.bzip2 0.425721 0.419981 101.37%
403.gcc 24.53855 24.2667 101.12%
429.mcf 0.060847 0.059944 101.51%
433.milc 0.646009 0.636119 101.55%
444.namd 1.383928 1.370614 100.97%
445.gobmk 5.836575 5.800225 100.63%
450.soplex 1.911257 1.895963 100.81%
456.hmmer 1.039565 1.032534 100.68%
458.sjeng 0.897401 0.885567 101.34%
464.h264ref 3.645908 3.577991 101.90%
470.lbm 0.049456 0.048398 102.19%
471.omnetpp 5.638575 5.60435 100.61%
bitmnp01 0.045738 0.045291 100.99%
cjpegv2data 0.304359 0.302833 100.50%
idctrn01 0.046433 0.045763 101.46%
quake2 4.534416 4.4952 100.87%
quake 2.688566 2.659208 101.10%
xcsoar 12.42545 12.30385 100.99%
linpack 0.038739 0.03803 101.86%
matrix01 0.053564 0.0528 101.45%
nbench 0.402867 0.395803 101.78%
tblook01 0.021265 0.021015 101.19%
ttsprk01 0.066384 0.065566 101.25%
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194459 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194457 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194456 91177308-0d34-0410-b5e6-96231b3b80d8
|