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;
}
llvm-svn: 142731
that the set of callee-saved registers is correct for the specific platform.
<rdar://problem/10313708> & ctor_dtor_count & ctor_dtor_count-2
llvm-svn: 142706
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>
llvm-svn: 142689
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.
llvm-svn: 142670
ZExtPromotedInteger and SExtPromotedInteger based on the operation we legalize.
SetCC return type needs to be legalized via PromoteTargetBoolean.
llvm-svn: 142660
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
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.
llvm-svn: 142644
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
the last compiler built for the previous flavour is used for the next,
for example the Debug clang compiler was being used for the initial build
of the Release LLVM. Flavors should be independent of each other. This
especially matters if the compiler built for the previous flavour doesn't
actually work!
llvm-svn: 142607
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
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
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
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
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
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
Add a peek function to let the Lexer look at a character arbitrarily
far ahead in the stream without consuming anything. We need this to
disambiguate numbers and operands of a paste operation. For example:
def foo#8i
Without lookahead the lexer will treat '8' as a number rather than as
part of a string to be pasted to form an identifier.
llvm-svn: 142512
Add Record names to be changed even on Records that aren't yet
registered. We need to be able to do this for paste functionality
because we do not want to register def names before they are unique
and that can only happen once all paste operations are done. This
change lets us update Record names formed by paste operations and
register the result later.
llvm-svn: 142510
Nick Lewycky