| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142741 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
element types, even though the element extraction code does. It is surprising
that this bug has been here for so long. Fixes <rdar://problem/10318778>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142740 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142738 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
multiply instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142737 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
elimination on them too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142735 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
able to constant fold load instructions where the argument is a constant.
Second, we should be able to watch multiple PHI nodes through the loop; this
patch only supports PHIs in loop headers, more can be done here.
With this patch, we now constant evaluate:
static const int arr[] = {1, 2, 3, 4, 5};
int test() {
int sum = 0;
for (int i = 0; i < 5; ++i) sum += arr[i];
return sum;
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142731 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142729 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142728 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142727 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
correctness along the way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142726 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
SHL inserts zeros from the right, thus even when the original
sign_extend_inreg value was of 1-bit, we need to sra.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142724 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
that the set of callee-saved registers is correct for the specific platform.
<rdar://problem/10313708> & ctor_dtor_count & ctor_dtor_count-2
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142706 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142704 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142691 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
The assumption in the back-end is that PHIs are not allowed at the start of the
landing pad block for SjLj exceptions.
<rdar://problem/10313708>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142689 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142687 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
I'd like to understand exactly why the links have changed and if a newer doxygen is required. This may be reapplied once we upgrade on llvm.org and it is fully tested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142686 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142684 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142683 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142682 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142681 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
This is from the same paper from Ball and Larus as the rest of the currently implemented heuristics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142677 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142675 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142673 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
expensive helper.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142672 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
the input and output vectors have different sizes. Patch by Xiaoyi Guo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142671 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Next step in the ongoing saga of NEON load/store assmebly parsing. Handle
VLD1 instructions that take a two-register register list.
Adjust the instruction definitions to only have the single encoded register
as an operand. The super-register from the pseudo is kept as an implicit def,
so passes which come after pseudo-expansion still know that the instruction
defines the other subregs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142670 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
ask for them. This is a divergence from gas' behavior, but it is correct per the documentation and allows us to forge ahead with roundtrip testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142669 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142667 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
accessors as well as Symbol iterators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142661 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
ZExtPromotedInteger and SExtPromotedInteger based on the operation we legalize.
SetCC return type needs to be legalized via PromoteTargetBoolean.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142658 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142657 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
all x86 systems. Sorry for the breakage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142656 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142653 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
type.
2. Fix a typo in CONCAT_VECTORS which exposed the bug in #1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142648 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142647 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
Patch by Ruben Van Boxem!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142646 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it's a bit more plausible to use this instead of CodePlacementOpt. The
code for this was shamelessly stolen from CodePlacementOpt, and then
trimmed down a bit. There doesn't seem to be much utility in returning
true/false from this pass as we may or may not have rewritten all of the
blocks. Also, the statistic of counting how many loops were aligned
doesn't seem terribly important so I removed it. If folks would like it
to be included, I'm happy to add it back.
This was probably the most egregious of the missing features, and now
I'm going to start gathering some performance numbers and looking at
specific loop structures that have different layout between the two.
Test is updated to include both basic loop alignment and nested loop
alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142645 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
canonical example I used when developing it, and is one of the primary
motivating real-world use cases for __builtin_expect (when burried under
a macro).
I'm working on more test cases here, but I'm trying to make sure both
that the pass is doing the right thing with the test cases and that they
aren't too brittle to changes elsewhere in the code generation pipeline.
Feedback and/or suggestions on how to test this are very welcome.
Especially feedback on whether testing the block comments is a good
strategy; I couldn't find any good examples to steal from but all the
other ideas I had were a lot uglier or more fragile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142644 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Python-fu could use some improving...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142643 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
custom isel lowering code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142642 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block frequency analyses. This differs substantially from the existing
block-placement pass in LLVM:
1) It operates on the Machine-IR in the CodeGen layer. This exposes much
more (and more precise) information and opportunities. Also, the
results are more stable due to fewer transforms ocurring after the
pass runs.
2) It uses the generalized probability and frequency analyses. These can
model static heuristics, code annotation derived heuristics as well
as eventual profile loading. By basing the optimization on the
analysis interface it can work from any (or a combination) of these
inputs.
3) It uses a more aggressive algorithm, both building chains from tho
bottom up to maximize benefit, and using an SCC-based walk to layout
chains of blocks in a profitable ordering without O(N^2) iterations
which the old pass involves.
The pass is currently gated behind a flag, and not enabled by default
because it still needs to grow some important features. Most notably, it
needs to support loop aligning and careful layout of loop structures
much as done by hand currently in CodePlacementOpt. Once it supports
these, and has sufficient testing and quality tuning, it should replace
both of these passes.
Thanks to Nick Lewycky and Richard Smith for help authoring & debugging
this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm
forgetting for reviewing and answering all my questions. Writing
a backend pass is *sooo* much better now than it used to be. =D
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142640 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142630 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
reading of the ARMv7 docs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142626 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
protected by ifdef either.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142623 91177308-0d34-0410-b5e6-96231b3b80d8
|