| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 195285
|
| |
|
|
|
|
|
| |
The instruction definitions incorrectly specified that popcntd and popcntw have
record forms; they do not. This mistake was causing invalid code generation.
llvm-svn: 195272
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block.
We now only allow breaking source order if the exit block frequency is
significantly higher than the other exit block. The actual bias is
currently under a flag so the best cut-off can be found; the flag
defaults to the old behavior. The idea is to get some benchmark coverage
over different values for the flag and pick the best one.
When we require the new frequency to be at least 20% higher than the old
frequency I see a 5% speedup on zlib's deflate when compressing a random
file on x86_64/westmere. Hal reported a small speedup on Fhourstones on
a BG/Q and no regressions in the test suite.
The test case is the full long_match function from zlib's deflate. I was
reluctant to add it for previous tweaks to branch probabilities because
it's large and potentially fragile, but changed my mind since it's an
important use case and more likely to break with all the current work
going into the PGO infrastructure.
Differential Revision: http://llvm-reviews.chandlerc.com/D2202
llvm-svn: 195265
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While not strictly necessary (the class has an invariant that
"setDebugInfoOffset" is called before "getDebugInfoOffset" - anyone
client that actually gets the default zero offset is buggy/broken) this
is consistent with the code as originally written and the removal of the
initialization was an accident in r195166.
Suggested by Manman Ren.
llvm-svn: 195263
|
| |
|
|
|
|
|
|
| |
units disabling cross-CU sharing.
Changes suggested by Manman Ren.
llvm-svn: 195262
|
| |
|
|
|
|
|
|
|
|
|
| |
Enhance the tests to actually require moves in C++11 mode, in addition
to testing the moved-from state. Further enhance the tests to cover
copy-assignment into a moved-from object and moving a large-state
object. (Note that we can't really test small-state vs. large-state as
that isn't an observable property of the API really.) This should finish
addressing review on r195239.
llvm-svn: 195261
|
| |
|
|
|
|
|
|
|
|
|
| |
instead of MipsPseudo
There's no test case for this commit. This is because it is doubtful that the
incorrect behaviour can actually trigger. When MSA is not enabled, the type
legalizer should have eliminated all occurrences of patterns the affected
pseudo-instruction could possibly match before instruction selection occurs.
llvm-svn: 195252
|
| |
|
|
| |
llvm-svn: 195245
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new set-like type which represents a set of preserved
analysis passes. The set is managed via the opaque PassT::ID() void*s.
The expected convenience templates for interacting with specific passes
are provided. It also supports a symbolic "all" state which is
represented by an invalid pointer in the set. This state is nicely
saturating as it comes up often. Finally, it supports intersection which
is used when finding the set of preserved passes after N different
transforms.
The pass API is then changed to return the preserved set rather than
a bool. This is much more self-documenting than the previous system.
Returning "none" is a conservatively correct solution just like
returning "true" from todays passes and not marking any passes as
preserved. Passes can also be dynamically preserved or not throughout
the run of the pass, and whatever gets returned is the binding state.
Finally, preserving "all" the passes is allowed for no-op transforms
that simply can't harm such things.
Finally, the analysis managers are changed to instead of blindly
invalidating all of the analyses, invalidate those which were not
preserved. This should rig up all of the basic preservation
functionality. This also correctly combines the preservation moving up
from one IR-layer to the another and the preservation aggregation across
N pass runs. Still to go is incrementally correct invalidation and
preservation across IR layers incrementally during N pass runs. That
will wait until we have a device for even exposing analyses across IR
layers.
While the core of this change is obvious, I'm not happy with the current
testing, so will improve it to cover at least some of the invalidation
that I can test easily in a subsequent commit.
llvm-svn: 195241
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Somehow, this ADT got missed which is moderately terrifying considering
the efficiency of move for it.
The code to implement move semantics for it is pretty horrible
currently but was written to reasonably closely match the rest of the
code. Unittests that cover both copying and moving (at a basic level)
added.
llvm-svn: 195239
|
| |
|
|
|
|
| |
[-Wunused-variable]
llvm-svn: 195238
|
| |
|
|
| |
llvm-svn: 195237
|
| |
|
|
| |
llvm-svn: 195230
|
| |
|
|
| |
llvm-svn: 195229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The FunctionPassManager is now itself a function pass. When run over
a function, it runs all N of its passes over that function. This is the
1:N mapping in the pass dimension only. This allows it to be used in
either a ModulePassManager or potentially some other manager that
works on IR units which are supersets of Functions.
This commit also adds the obvious adaptor to map from a module pass to
a function pass, running the function pass across every function in the
module.
The test has been updated to use this new pattern.
llvm-svn: 195192
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of permanently outputting "MVLL" as the file checksum, clang
will create gcno and gcda checksums by hashing the destination block
numbers of every arc. This allows for llvm-cov to check if the two gcov
files are synchronized.
Regenerated the test files so they contain the checksum. Also added
negative test to ensure error when the checksums don't match.
llvm-svn: 195191
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
llvm-svn: 195189
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Masking operations (where only some number of the low bits are being kept) are
selected to rldicl(x, 0, mb). If x is a logical right shift (which would become
rldicl(y, 64-n, n)), we might be able to fold the two instructions together:
rldicl(rldicl(x, 64-n, n), 0, mb) -> rldicl(x, 64-n, mb) for n <= mb
The right shift is really a left rotate followed by a mask, and if the explicit
mask is a more-restrictive sub-mask of the mask implied by the shift, only one
rldicl is needed.
llvm-svn: 195185
|
| |
|
|
|
|
|
| |
and not polymorphically deleted and they are the only thing that derive
from DIE.
llvm-svn: 195183
|
| |
|
|
|
|
| |
and LexicalScopes, we're not using it.
llvm-svn: 195182
|
| |
|
|
| |
llvm-svn: 195181
|
| |
|
|
| |
llvm-svn: 195180
|
| |
|
|
| |
llvm-svn: 195179
|
| |
|
|
| |
llvm-svn: 195175
|
| |
|
|
| |
llvm-svn: 195173
|
| |
|
|
| |
llvm-svn: 195171
|
| |
|
|
| |
llvm-svn: 195170
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Emit DW_TAG_type_units into the debug_info section using compile unit
headers. This is bogus/unusable by debuggers, but testable and provides
more isolated review.
Subsequent patches will include support for type unit headers and
emission into the debug_types section, as well as comdat grouping the
types based on their hash. Also the CompileUnit type will be renamed
'Unit' and relevant portions pulled out into respective CompileUnit and
TypeUnit types.
llvm-svn: 195166
|
| |
|
|
|
|
| |
accelarator insertion in preparation for a second use of this code from type units.
llvm-svn: 195164
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are slicing an array of Value pointers and process those slices in a loop.
The problem is that we might invalidate a later slice by vectorizing a former
slice.
Use a WeakVH to track the pointer. If the pointer is deleted or RAUW'ed we can
tell.
The test case will only fail when running with libgmalloc.
radar://15498655
llvm-svn: 195162
|
| |
|
|
| |
llvm-svn: 195161
|
| |
|
|
|
|
|
|
|
|
| |
Instead of processing relocation for branch to stubs right away, emit a
modified relocation and add it to queue to be resolved later when final load
address is known.
This resolves seven MIPS MCJIT issues that were caused by missing relocation
fixups at the end.
llvm-svn: 195157
|
| |
|
|
|
|
|
|
| |
intended.
Reviewed by Tom
llvm-svn: 195156
|
| |
|
|
|
|
|
|
|
|
| |
The object files we support use null terminated strings, so there is no way to
support these.
This patch adds an assert to catch bad API use and an error check in the .ll
parser.
llvm-svn: 195155
|
| |
|
|
| |
llvm-svn: 195153
|
| |
|
|
| |
llvm-svn: 195152
|
| |
|
|
|
|
|
| |
Added constness to methods that shouldn't modify objects. Replaced
operator[] lookup in maps with find() instead.
llvm-svn: 195151
|
| |
|
|
| |
llvm-svn: 195150
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step to fix pr17918.
It extends the .section directive a bit, inspired by what the ELF one looks
like. The problem with using linkonce is that given
.section foo
.linkonce....
.section foo
.linkonce
we would already have switched sections when getting to .linkonce. The cleanest
solution seems to be to add the comdat information in the .section itself.
llvm-svn: 195148
|
| |
|
|
|
|
| |
Caught by Aaron Ballman.
llvm-svn: 195138
|
| |
|
|
|
|
| |
attempt at this, this time doing a clean build on Linux, and running the LLVM, clang, and extra tests, to try to make sure there's no problems.
llvm-svn: 195134
|
| |
|
|
| |
llvm-svn: 195129
|
| |
|
|
|
|
|
|
|
|
|
| |
Hard float for mips16 means essentially to compile as soft float but to
use a runtime library for soft float that is written with native mips32
floating point instructions (those runtime routines run in mips32 hard
float mode).
The patch reviewed by Reed Kotler.
llvm-svn: 195123
|
| |
|
|
| |
llvm-svn: 195122
|
| |
|
|
| |
llvm-svn: 195121
|
| |
|
|
|
|
|
| |
we can emit various sections in any order.
No functional change.
llvm-svn: 195120
|
| |
|
|
| |
llvm-svn: 195119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
order of slices of the alloca which have exactly the same size and other
properties. This was found by a perniciously unstable sort
implementation used to flush out buggy uses of the algorithm.
The fundamental idea is that findCommonType should return the best
common type it can find across all of the slices in the range. There
were two bugs here previously:
1) We would accept an integer type smaller than a byte-width multiple,
and if there were different bit-width integer types, we would accept
the first one. This caused an actual failure in the testcase updated
here when the sort order changed.
2) If we found a bad combination of types or a non-load, non-store use
before an integer typed load or store we would bail, but if we found
the integere typed load or store, we would use it. The correct
behavior is to always use an integer typed operation which covers the
partition if one exists.
While a clever debugging sort algorithm found problem #1 in our existing
test cases, I have no useful test case ideas for #2. I spotted in by
inspection when looking at this code.
llvm-svn: 195118
|
| |
|
|
|
|
| |
Patch by Dmitri Shtilman!
llvm-svn: 195116
|
| |
|
|
| |
llvm-svn: 195103
|