| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ``nprocs`` command does not exist under Mac OSX so use
``sysctl`` instead on that platform.
Whilst I'm here
* Use ``pclose()`` instead of ``fclose()`` which the ``popen()``
documentation says should be used.
* Check for errors that were previously unhandled.
Differential Revision: http://reviews.llvm.org/D20409
llvm-svn: 270172
|
|
|
|
|
|
| |
Reviewed by Matt Arsenault in http://reviews.llvm.org/D16311
llvm-svn: 270171
|
|
|
|
|
|
|
|
|
|
|
| |
an instruction.
Use the previously introduced RepairingPlacement class to split the code
computing the repairing placement from the code doing the actual
placement. That way, we will be able to consider different placement and
then, only apply the best one.
llvm-svn: 270168
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When assigning the register banks we may have to insert repairing code
to move already assigned values accross register banks.
Introduce a few helper classes to keep track of what is involved in the
repairing of an operand:
- InsertPoint and its derived classes record the positions, in the CFG,
where repairing has to be inserted.
- RepairingPlacement holds all the insert points for the repairing of an
operand plus the kind of action that is required to do the repairing.
This is going to be used to keep track of how the repairing should be
done, while comparing different solutions for an instruction. Indeed, we
will need the repairing placement to capture the cost of a solution and
we do not want to compute it a second time when we do the actual
repairing.
llvm-svn: 270167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register bank twice.
Prior to this change, we were checking if the assignment for the current
machine operand was matching, then we would check if the mismatch
requires to insert repair code.
We actually already have this information from the first check, so just
pass it along.
NFCI.
llvm-svn: 270166
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sorry for the lack testcase. There is one in the pr, but it depends on
std::sort and the .ll version is 110 lines, so I don't think it is
wort it.
The bug was that we were sorting after adding a terminator, and the
sorting algorithm could end up putting the terminator in the middle of
the List vector.
With that we would create a Spans map entry keyed on nullptr which would
then be added to CUs and fail in that sorting.
llvm-svn: 270165
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This helper class will be used to represent the cost of mapping an
instruction to a specific register bank.
The particularity of these costs is that they are mostly local, thus the
frequency of the basic block is irrelevant. However, for few
instructions (e.g., phis and terminators), the cost may be non-local and
then, we need to account for the frequency of the involved basic blocks.
This will be used by the greedy mode I am working on.
llvm-svn: 270163
|
|
|
|
| |
llvm-svn: 270161
|
|
|
|
|
|
| |
This test covers strings after load command structs and zero fill bytes.
llvm-svn: 270159
|
|
|
|
|
|
|
|
| |
Now that MachO load command fields are fully covered we can fill unaccounted for bytes with 0. That allows us to sparsely specify YAML to simplify tests.
Simplifying load_commands test accordingly.
llvm-svn: 270158
|
|
|
|
|
|
| |
symbols on x86-64.
llvm-svn: 270157
|
|
|
|
| |
llvm-svn: 270156
|
|
|
|
| |
llvm-svn: 270155
|
|
|
|
|
|
|
|
| |
Before r257832, the threshold used by SimpleInliner was explicitly specified or generated from opt levels and passed to the base class Inliner's constructor. There, it was first overridden by explicitly specified -inline-threshold. The refactoring in r257832 did not preserve this behavior for all opt levels. This change brings back the original behavior.
Differential Revision: http://reviews.llvm.org/D20452
llvm-svn: 270153
|
|
|
|
| |
llvm-svn: 270152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sequences of range checks expressed using guards, like
guard((I - 2) u< L)
guard((I - 1) u< L)
guard((I + 0) u< L)
guard((I + 1) u< L)
guard((I + 2) u< L)
can sometimes be combined into a smaller sequence:
guard((I - 2) u< L AND (I + 2) u< L)
if we can prove that (I - 2) u< L AND (I + 2) u< L implies all of checks
expressed in the previous sequence.
This change teaches GuardWidening to do this kind of merging when
feasible.
llvm-svn: 270151
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using Chandler's words from r265331:
This commit was greatly exacerbating PR17409 and effectively regressed
build time for lot of (very large) code when compiled with ASan or MSan.
PR17409 is fixed by r269249, so this is fine to reapply r263460.
Original commit message:
The bad behavior happens when we have a function with a long linear
chain of basic blocks, and have a live range spanning most of this
chain, but with very few uses.
Let say we have only 2 uses.
The Hopfield network is only seeded with two active blocks where the
uses are, and each iteration of the outer loop in
`RAGreedy::growRegion()` only adds two new nodes to the network due to
the completely linear shape of the CFG. Meanwhile,
`SpillPlacer->iterate()` visits the whole set of discovered nodes, which
adds up to a quadratic algorithm.
This is an historical accident effect from r129188.
When the Hopfield network is expanding, most of the action is happening
on the frontier where new nodes are being added. The internal nodes in
the network are not likely to be flip-flopping much, or they will at
least settle down very quickly. This means that while
`SpillPlacer->iterate()` is recomputing all the nodes in the network, it
is probably only the two frontier nodes that are changing their output.
Instead of recomputing the whole network on each iteration, we can
maintain a SparseSet of nodes that need to be updated:
- `SpillPlacement::activate()` adds the node to the todo list.
- When a node changes value (i.e., `update()` returns true), its
neighbors are added to the todo list.
- `SpillPlacement::iterate()` only updates the nodes in the list.
The result of Hopfield iterations is not necessarily exact. It should
converge to a local minimum, but there is no guarantee that it will find
a global minimum. It is possible that updating nodes in a different
order will cause us to switch to a different local minimum. In other
words, this is not NFC, but although I saw a few runtime improvements
and regressions when I benchmarked this change, those were side effects
and actually the performance change is in the noise as expected.
Huge thanks to Jakob Stoklund Olesen <stoklund@2pi.dk> for his
feedbacks, guidance and time for the review.
llvm-svn: 270149
|
|
|
|
|
|
| |
Addresses r270095's code review.
llvm-svn: 270147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Work around crashes in ``__sanitizer_malloc_hook()`` under Mac OSX.
Under Mac OSX we intercept calls to malloc before thread local
storage is initialised leading to a crash when accessing
``AllocTracer``. To workaround this ``AllocTracer`` is only accessed
in the hook under Linux. For symmetry ``__sanitizer_free_hook()``
is also modified in the same way.
To support this change a set of new macros
LIBFUZZER_LINUX and LIBFUZZER_APPLE has been defined which can be
used to check the target being compiled for.
Differential Revision: http://reviews.llvm.org/D20402
llvm-svn: 270145
|
|
|
|
|
|
|
|
| |
This removes the subclasses of ProfileSummary, moves the members of the derived classes to the base class.
Differential Revision: http://reviews.llvm.org/D20390
llvm-svn: 270143
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When matching an interleaved load to an ldN pattern, the interleaved access
pass checks that all users of the load are shuffles. If the load is used by an
instruction other than a shuffle, the pass gives up and an ldN is not
generated. This patch considers users of the load that are extractelement
instructions. It attempts to modify the extracts to use one of the available
shuffles rather than the load. After the transformation, the load is only used
by shuffles and will then be matched with an ldN pattern.
Differential Revision: http://reviews.llvm.org/D20250
llvm-svn: 270142
|
|
|
|
| |
llvm-svn: 270139
|
|
|
|
| |
llvm-svn: 270137
|
|
|
|
|
|
|
|
| |
This splits ProfileSummary into two classes: a ProfileSummary class that has methods to convert from/to metadata and a ProfileSummaryBuilder class that computes the profiles summary which is in ProfileData.
Differential Revision: http://reviews.llvm.org/D20314
llvm-svn: 270136
|
|
|
|
|
|
|
|
|
|
| |
address and result of load instructions
This patch fixes https://llvm.org/bugs/show_bug.cgi?id=27703.
If there is a sequence of one or more load instructions, each loaded value is used as address of later load instruction, bitcast is necessary to change the value type, don't optimize it.
llvm-svn: 270135
|
|
|
|
|
|
|
| |
Patch is awaiting review here:
http://reviews.llvm.org/D20434
llvm-svn: 270128
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This re-applies r270115.
Many of the MachO load commands can have data appended after the command structure. This data is frequently strings, but can actually be anything. This patch adds support for three optional fields on load command yaml descriptions.
The new PayloadString YAML field is populated with the data after load commands known to have strings as extra data.
The new ZeroPadBytes YAML field is a count of zero'd bytes after the end of the load command structure before the next command. This can apply anywhere in the file. MachO2YAML verifies that bytes are zero before populating this field, and YAML2MachO will add zero'd bytes.
The new PayloadBytes YAML field stores all bytes after the end of the load command structure before the next command if they are non-zero. This is a catch all for all unhandled bytes. If MachO2Yaml populates PayloadBytes it will not populate ZeroPadBytes, instead zero'd bytes will be in the PayloadBytes structure.
llvm-svn: 270124
|
|
|
|
|
|
|
|
| |
This reverts commit r270115.
This failed on several builders using GCC.
llvm-svn: 270121
|
|
|
|
| |
llvm-svn: 270118
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many of the MachO load commands can have data appended after the command structure. This data is frequently strings, but can actually be anything. This patch adds support for three optional fields on load command yaml descriptions.
The new PayloadString YAML field is populated with the data after load commands known to have strings as extra data.
The new ZeroPadBytes YAML field is a count of zero'd bytes after the end of the load command structure before the next command. This can apply anywhere in the file. MachO2YAML verifies that bytes are zero before populating this field, and YAML2MachO will add zero'd bytes.
The new PayloadBytes YAML field stores all bytes after the end of the load command structure before the next command if they are non-zero. This is a catch all for all unhandled bytes. If MachO2Yaml populates PayloadBytes it will not populate ZeroPadBytes, instead zero'd bytes will be in the PayloadBytes structure.
llvm-svn: 270115
|
|
|
|
| |
llvm-svn: 270113
|
|
|
|
| |
llvm-svn: 270111
|
|
|
|
| |
llvm-svn: 270110
|
|
|
|
|
|
|
|
|
| |
Since the calls don't return, the instruction afterwards will never run,
and is just taking up unnecessary space in the binary.
Differential Revision: http://reviews.llvm.org/D20406
llvm-svn: 270109
|
|
|
|
|
|
|
|
| |
A baby step toward translating DIType records to CodeView.
This does not (yet) combine the record length with the record data. I'm going back and forth trying to determine if that's a good idea.
llvm-svn: 270106
|
|
|
|
|
|
|
| |
InterleavedAccessPass is an IR-level pass, so this change will enable testing
it with opt. This is part of D20250.
llvm-svn: 270101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getRegAsmName ends up making a copy of the register's name in order to
make a lower-case version of it. This is bad because
getRegForInlineAsmConstraint, it's sole caller, does a lowercase
comparison anyway.
This resulted in a significant regression in compile time for the Linux
kernel because getRegAsmName is called in a loop by
getRegForInlineAsmConstraint.
Instead, forgo the call to lower in getRegAsmName and have it return a
StringRef.
No functionality change is intended.
llvm-svn: 270099
|
|
|
|
| |
llvm-svn: 270096
|
|
|
|
|
|
| |
This avoids passing a TargetMachine in a few places.
llvm-svn: 270095
|
|
|
|
| |
llvm-svn: 270093
|
|
|
|
|
|
|
| |
Remove a comment about not supporting LRVH/STRVH from the README
LRVH/STRVH are being generated as of r269688
llvm-svn: 270092
|
|
|
|
| |
llvm-svn: 270091
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20441
llvm-svn: 270088
|
|
|
|
|
|
|
| |
Problem Was exposed by -Wstring-conversion
llvm-svn: 270087
|
|
|
|
| |
llvm-svn: 270081
|
|
|
|
| |
llvm-svn: 270080
|
|
|
|
|
|
|
|
|
|
|
|
| |
antidependency breaker
Previously, specifying -post-RA-scheduler=true had the side effect of
disabling the antidependency breaker, yielding different behavior than
if the post-RA-scheduler was enabled via the scheduling model.
Differential Revision: http://reviews.llvm.org/D20186
llvm-svn: 270077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It broke buildbot:
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/4817/steps/ninja%20check%201/logs/stdio
Actually it is just because D20273 not yet commited, but these 2 were crossing with each other,
and I`ll better find the way to land them separatelly soon.
Initial commit message:
[llvm-mc] - Teach llvm-mc to generate compressed debug sections in zlib style.
Before this patch llvm-mc generated zlib-gnu styled sections.
That means no SHF_COMPRESSED flag was set, magic 'zlib' signature
was used in combination with full size field. Sections were renamed to "*.z*".
This patch reimplements the compression style to zlib one as zlib-gnu looks
to be depricated everywhere.
Differential revision: http://reviews.llvm.org/D20331
llvm-svn: 270075
|
|
|
|
| |
llvm-svn: 270074
|
|
|
|
|
|
|
|
|
| |
There are at least 2 places (DAGCombiner, X86ISelLowering) where this could be used instead
of ad-hoc and watered down code that is trying to match a power-of-2 pattern.
Differential Revision: http://reviews.llvm.org/D20439
llvm-svn: 270073
|