It was out of sync with the description in configure.ac/config.h.in.
Also re-alphabetize it from its position when it was LLVM_HOST_TRIPLE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145213 91177308-0d34-0410-b5e6-96231b3b80d8
I think this is the last of autoupgrade that can be removed in 3.1.
Can the atomic upgrade stuff also go?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145169 91177308-0d34-0410-b5e6-96231b3b80d8
tablegen patterns for scalar FMA4 operations and intrinsic. Also
add tests for vfmaddsd.
Patch by Jan Sjodin
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145133 91177308-0d34-0410-b5e6-96231b3b80d8
and code model. This eliminates the need to pass OptLevel flag all over the
place and makes it possible for any codegen pass to use this information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144788 91177308-0d34-0410-b5e6-96231b3b80d8
It triggers generating insane executables with both binutils-2.19.1(msysgit) and 2.22.51.20111013(cygwin).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144621 91177308-0d34-0410-b5e6-96231b3b80d8
Two new TargetInstrInfo hooks lets the target tell ExecutionDepsFix
about instructions with partial register updates causing false unwanted
dependencies.
The ExecutionDepsFix pass will break the false dependencies if the
updated register was written in the previoius N instructions.
The small loop added to sse-domains.ll runs twice as fast with
dependency-breaking instructions inserted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144602 91177308-0d34-0410-b5e6-96231b3b80d8
and stores capture) to permit the caller to see each capture point and decide
whether to continue looking.
Use this inside memdep to do an analysis that basicaa won't do. This lets us
solve another devirtualization case, fixing PR8908!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144580 91177308-0d34-0410-b5e6-96231b3b80d8
These annotations are disabled entirely when either ENABLE_THREADS is off, or
building a release build. When enabled, they add calls to functions with no
statements to ManagedStatic's getters.
Use these annotations to inform tsan that the race used inside ManagedStatic
initialization is actually benign. Thanks to Kostya Serebryany for helping
write this patch!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144567 91177308-0d34-0410-b5e6-96231b3b80d8
time it is queried to compute the probability of a single successor.
This makes computing the probability of every successor of a block in
sequence... really really slow. ;] This switches to a linear walk of the
successors rather than a quadratic one. One of several quadratic
behaviors slowing this pass down.
I'm not really thrilled with moving the sum code into the public
interface of MBPI, but I don't (at the moment) have ideas for a better
interface. My direction I'm thinking in for a better interface is to
have MBPI actually retain much more state and make *all* of these
queries cheap. That's a lot of work, and would require invasive changes.
Until then, this seems like the least bad (ie, least quadratic)
solution. Suggestions welcome.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144530 91177308-0d34-0410-b5e6-96231b3b80d8
correctly handle blocks whose successor weights sum to more than
UINT32_MAX. This is slightly less efficient, but the entire thing is
already linear on the number of successors. Calling it within any hot
routine is a mistake, and indeed no one is calling it. It also
simplifies the code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144527 91177308-0d34-0410-b5e6-96231b3b80d8
the sum of the edge weights not overflowing uint32, and crashed when
they did. This is generally safe as BranchProbabilityInfo tries to
provide this guarantee. However, the CFG can get modified during codegen
in a way that grows the *sum* of the edge weights. This doesn't seem
unreasonable (imagine just adding more blocks all with the default
weight of 16), but it is hard to come up with a case that actually
triggers 32-bit overflow. Fortuately, the single-source GCC build is
good at this. The solution isn't very pretty, but its no worse than the
previous code. We're already summing all of the edge weights on each
query, we can sum them, check for an overflow, compute a scale, and sum
them again.
I've included a *greatly* reduced test case out of the GCC source that
triggers it. It's a pretty lame test, as it clearly is just barely
triggering the overflow. I'd like to have something that is much more
definitive, but I don't understand the fundamental pattern that triggers
an explosion in the edge weight sums.
The buggy code is duplicated within this file. I'll colapse them into
a single implementation in a subsequent commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144526 91177308-0d34-0410-b5e6-96231b3b80d8
expensive the most useful interface to this analysis is.
Fun story -- it's also not correct. That's getting fixed in another
patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144523 91177308-0d34-0410-b5e6-96231b3b80d8
The old naming scheme (load/use/def/store) can be traced back to an old
linear scan article, but the names don't match how slots are actually
used.
The load and store slots are not needed after the deferred spill code
insertion framework was deleted.
The use and def slots don't make any sense because we are using
half-open intervals as is customary in C code, but the names suggest
closed intervals. In reality, these slots were used to distinguish
early-clobber defs from normal defs.
The new naming scheme also has 4 slots, but the names match how the
slots are really used. This is a purely mechanical renaming, but some
of the code makes a lot more sense now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144503 91177308-0d34-0410-b5e6-96231b3b80d8
RegAllocGreedy has been the default for six months now.
Deleting RegAllocLinearScan makes it possible to also delete
VirtRegRewriter and clean up the spiller code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144475 91177308-0d34-0410-b5e6-96231b3b80d8
When this field is true it means that the load is from constant (runt-time or compile-time) and so can be hoisted from loops or moved around other memory accesses
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144100 91177308-0d34-0410-b5e6-96231b3b80d8
to fix the types section (all types, not just global types), and testcases.
The code to do the final emission is disabled by default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143923 91177308-0d34-0410-b5e6-96231b3b80d8
the mailing list. Suggestions for other statistics to collect would be
awesome. =]
Currently these are implemented as a separate pass guarded by a separate
flag. I'm not thrilled by that, but I wanted to be able to collect the
statistics for the old code placement as well as the new in order to
have a point of comparison. I'm planning on folding them into the single
pass if / when there is only one pass of interest.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143537 91177308-0d34-0410-b5e6-96231b3b80d8
-g flag. In this part we generate the .file for the source being assembled and
the .loc's for the assembled instructions.
The next part will be to generate the dwarf Compile Unit DIE and a dwarf
subprogram DIE for each non-temporary label.
Once the next part is done test cases will be added. rdar://9275556
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143509 91177308-0d34-0410-b5e6-96231b3b80d8
Add a test case for the edge case that triggers this. Thanks to Chandler for bringing this to my attention.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142794 91177308-0d34-0410-b5e6-96231b3b80d8
introduce no-return or unreachable heuristics.
The return heuristics from the Ball and Larus paper don't work well in
practice as they pessimize early return paths. The only good hitrate
return heuristics are those for:
- NULL return
- Constant return
- negative integer return
Only the last of these three can possibly require significant code for
the returning block, and even the last is fairly rare and usually also
a constant. As a consequence, even for the cold return paths, there is
little code on that return path, and so little code density to be gained
by sinking it. The places where sinking these blocks is valuable (inner
loops) will already be weighted appropriately as the edge is a loop-exit
branch.
All of this aside, early returns are nearly as common as all three of
these return categories, and should actually be predicted as taken!
Rather than muddy the waters of the static predictions, just remain
silent on returns and let the CFG itself dictate any layout or other
issues.
However, the return heuristic was flagging one very important case:
unreachable. Unfortunately it still gave a 1/4 chance of the
branch-to-unreachable occuring. It also didn't do a rigorous job of
finding those blocks which post-dominate an unreachable block.
This patch builds a more powerful analysis that should flag all branches
to blocks known to then reach unreachable. It also has better worst-case
runtime complexity by not looping through successors for each block. The
previous code would perform an N^2 walk in the event of a single entry
block branching to N successors with a switch where each successor falls
through to the next and they finally fall through to a return.
Test case added for noreturn heuristics. Also doxygen comments improved
along the way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142793 91177308-0d34-0410-b5e6-96231b3b80d8
two more subtle routines to the bottom and expand on their cautionary
comments a bit. No functionality or actual interface change here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142789 91177308-0d34-0410-b5e6-96231b3b80d8
a single class. Previously it was split between two classes, one
internal and one external. The concern seemed to center around exposing
the weights used, but those can remain confined to the implementation
file.
Having a single class to maintain the state and analyses in use will
also simplify several of the enhancements I want to make to our static
heuristics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142783 91177308-0d34-0410-b5e6-96231b3b80d8
to bring it under direct test instead of merely indirectly testing it in
the BlockFrequencyInfo pass.
The next step is to start adding tests for the various heuristics
employed, and to start fixing those heuristics once they're under test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142778 91177308-0d34-0410-b5e6-96231b3b80d8
to get important constant branch probabilities and use them for finding
the best branch out of a set of possibilities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142762 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142605 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142518 91177308-0d34-0410-b5e6-96231b3b80d8
Add a Record constructor that takes the Record name as an Init. This
is more work toward paste functionality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142508 91177308-0d34-0410-b5e6-96231b3b80d8
Record names may not be fully resolved at this point so ask for the
record name as a string explicitly. This avoids a potential assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142502 91177308-0d34-0410-b5e6-96231b3b80d8
Allow template arg names to be Inits. This is further work to
implement paste as it allows template names to participate in paste
operations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142500 91177308-0d34-0410-b5e6-96231b3b80d8
Add a couple of utility functions to take a variable name and qualify
it with the namespace of the enclosing class and/or multiclass. This
is inpreparation for making template arg names first-class Inits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142498 91177308-0d34-0410-b5e6-96231b3b80d8
Make the VarInit name an Init itself. We need this to implement paste
functionality so we can reference variables whose names are not yet
completely resolved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142497 91177308-0d34-0410-b5e6-96231b3b80d8
Add accessors to get Record values by Init name. This lets us look up
Record values whose names are not yet fully resolved. More work
toward paste.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142496 91177308-0d34-0410-b5e6-96231b3b80d8
Add a utility to get the name init and get the string representation
of the name. This will be used for paste functionality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142495 91177308-0d34-0410-b5e6-96231b3b80d8
Add a couple of utility functions to get at the name init and return
the name init as a string. This will be used for paste functionality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142494 91177308-0d34-0410-b5e6-96231b3b80d8
layer already had support for printing the results of this analysis, but
the wiring was missing.
Now that printing the analysis works, actually bring some of this
analysis, and the BranchProbabilityInfo analysis that it wraps, under
test! I'm planning on fixing some bugs and doing other work here, so
having a nice place to add regression tests and a way to observe the
results is really useful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142491 91177308-0d34-0410-b5e6-96231b3b80d8
Clean up the patterns, fix comments, and avoid confusing both tools
and coders. Note that the special adds/subs SelectionDAG nodes no
longer have the dummy cc_out operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142397 91177308-0d34-0410-b5e6-96231b3b80d8
Some of these can be true at the same time and there are a lot to add,
so this should be turned into a bitfield. Some of the other accessors
should probably be folded into this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142318 91177308-0d34-0410-b5e6-96231b3b80d8
