| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 142667
|
| |
|
|
|
|
| |
accessors as well as Symbol iterators.
llvm-svn: 142661
|
| |
|
|
|
|
|
|
| |
ZExtPromotedInteger and SExtPromotedInteger based on the operation we legalize.
SetCC return type needs to be legalized via PromoteTargetBoolean.
llvm-svn: 142660
|
| |
|
|
| |
llvm-svn: 142658
|
| |
|
|
| |
llvm-svn: 142657
|
| |
|
|
| |
llvm-svn: 142653
|
| |
|
|
|
|
|
|
| |
type.
2. Fix a typo in CONCAT_VECTORS which exposed the bug in #1.
llvm-svn: 142648
|
| |
|
|
|
|
| |
Patch by Ruben Van Boxem!
llvm-svn: 142646
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 142645
|
| |
|
|
|
|
| |
custom isel lowering code.
llvm-svn: 142642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 142641
|
| |
|
|
|
|
| |
Clang.
llvm-svn: 142631
|
| |
|
|
| |
llvm-svn: 142630
|
| |
|
|
|
|
| |
reading of the ARMv7 docs.
llvm-svn: 142626
|
| |
|
|
|
|
| |
protected by ifdef either.
llvm-svn: 142623
|
| |
|
|
|
|
| |
top-down scheduling and top-down scheduling is going away.
llvm-svn: 142621
|
| |
|
|
|
|
| |
because they don't support physical register dependencies.
llvm-svn: 142620
|
| |
|
|
|
|
| |
versions. This fixes some roundtripping failures.
llvm-svn: 142618
|
| |
|
|
| |
llvm-svn: 142615
|
| |
|
|
|
|
|
|
| |
AsmParser. This patch adds validation for target data layout strings upon
construction of TargetData objects. An attempt to construct a TargetData object
from a malformed string will trigger an assertion.
llvm-svn: 142605
|
| |
|
|
|
|
|
| |
causing one of the unit tests to infinitely loop, which resulted in the
buildbots stalling.
llvm-svn: 142604
|
| |
|
|
| |
llvm-svn: 142593
|
| |
|
|
| |
llvm-svn: 142592
|
| |
|
|
| |
llvm-svn: 142591
|
| |
|
|
| |
llvm-svn: 142583
|
| |
|
|
| |
llvm-svn: 142581
|
| |
|
|
| |
llvm-svn: 142579
|
| |
|
|
|
|
| |
definition is unused, and enhance it so it can tell that functions which are only used by a blockaddress are in fact dead. This probably doesn't happen much on most code, but the Linux kernel's _THIS_IP_ can trigger this issue with blockaddress. (GlobalDCE can also handle the given tescase, but we only run that at -O3.) Found while looking at PR11180.
llvm-svn: 142572
|
| |
|
|
| |
llvm-svn: 142569
|
| |
|
|
| |
llvm-svn: 142567
|
| |
|
|
|
|
| |
correctly in GetStringLength, fixing PR11181!
llvm-svn: 142558
|
| |
|
|
| |
llvm-svn: 142557
|
| |
|
|
|
|
| |
Patch by Pranav Bhandarkar!
llvm-svn: 142556
|
| |
|
|
|
|
| |
rdar://10291355
llvm-svn: 142550
|
| |
|
|
|
|
|
|
|
| |
When checking the availability of instructions using the TLI, a 'promoted'
instruction IS available. It means that the value is bitcasted to another type
for which there is an operation. The correct check for the availablity of an
instruction is to check if it should be expanded.
llvm-svn: 142542
|
| |
|
|
| |
llvm-svn: 142537
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
addresses when optimizing for size.
On spec/gcc, this caused a codesize improvement of ~1.9% for ARM mode and ~4.9% for Thumb(2) mode. This is
codesize including literal pools.
The pools themselves doubled in size for ARM mode and quintupled for Thumb mode, leaving suggestion that there
is still perhaps redundancy in LLVM's use of constant pools that could be decreased by sharing entries.
Fixes PR11087.
llvm-svn: 142530
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a paste operator '#' to take two identifier-like strings and joint
them. Internally paste gets represented as a !strconcat() with any
necessary casts to string added.
This will be used to implement basic for loop functionality as in:
for i = [0, 1, 2, 3, 4, 5, 6, 7] {
def R#i : Register<...>
}
llvm-svn: 142525
|
| |
|
|
|
|
|
| |
During multiclass def instantiation, replace NAME in any expressions
with the value of the def or defm ID.
llvm-svn: 142524
|
| |
|
|
|
|
|
| |
Parse and process a defm prefix as an Init expression. This allows
paste operations to create defm prefixes.
llvm-svn: 142523
|
| |
|
|
|
|
|
| |
Allow def and defm IDs to be general values. We need this for paste
functionality.
llvm-svn: 142522
|
| |
|
|
|
|
|
|
| |
Stop parsing a value if we are in name parsing mode and we see a left
brace. A left brace indicates the start of an object body when we are
parsing a name.
llvm-svn: 142521
|
| |
|
|
|
|
|
| |
Augment the value parser to respect the parse mode and not error if an
ID doesn't map to an object and we are in name parsing mode.
llvm-svn: 142520
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a mode control to value and ID parsers. The two modes are:
- Parse a value. Expect the parsed ID to map to an existing object.
- Parse a name. Expect the parsed ID to not map to any existing object.
The first is used when parsing an identifier to be looked up, for
example a record field or template argument. The second is used for
parsing declarations. Paste functionality implies that declarations
can contain arbitrary expressions so we need to be able to call into
the general value parser to parse declarations with paste operators.
So we need a way to parse a value-like thing without expecting that
the result will map to some existing object. This parse mode provides
that.
llvm-svn: 142519
|
| |
|
|
|
|
|
|
| |
Add a Value named "NAME" to each Record. This will be set to the def or defm
name when instantiating multiclasses. This will replace the #NAME# processing
hack once paste functionality is in place.
llvm-svn: 142518
|
| |
|
|
|
|
| |
Get the Record name as a string explicitly to avoid asserts.
llvm-svn: 142517
|
| |
|
|
|
|
| |
Get the Record name as a string explicitly to avoid asserts.
llvm-svn: 142516
|
| |
|
|
|
|
| |
Get the Record name as a string explicitly to avoid asserts.
llvm-svn: 142515
|
| |
|
|
|
|
| |
Get the Record name by string explicitly to avoid potential asserts.
llvm-svn: 142514
|
| |
|
|
|
|
|
|
| |
Use lookahead to determine whether a number is really a number or is
part of something forming an identifier. This won't come into play
until the paste operator is recognized as a unique token.
llvm-svn: 142513
|