Otherwise, we would try to re-optimize them with Polly-ACC and possibly even
generate kernels that try to offload themselves, which does not work as the
GPURuntime is not available on the accelerator and also does not make any
sense.
llvm-svn: 277589
Previously we supported only sorting by name.
When there are nested section sorting commands in linker script, there can be at most 1
level of nesting for section sorting commands.
SORT_BY_NAME (SORT_BY_ALIGNMENT (wildcard section pattern)). It will sort the input
sections by name first, then by alignment if 2 sections have the same name.
SORT_BY_ALIGNMENT (SORT_BY_NAME (wildcard section pattern)). It will sort the input
sections by alignment first, then by name if 2 sections have the same alignment.
SORT_BY_NAME (SORT_BY_NAME (wildcard section pattern)) is treated the same as SORT_
BY_NAME (wildcard section pattern).
SORT_BY_ALIGNMENT (SORT_BY_ALIGNMENT (wildcard section pattern)) is treated the
same as SORT_BY_ALIGNMENT (wildcard section pattern).
All other nested section sorting commands are invalid.
Patch implements that all above.
Differential revision: https://reviews.llvm.org/D23019
llvm-svn: 277583
required by MSVC 2013.
This also makes the repeating pass wrapper assignable. Mildly
unfortunate as it means we can't use a const member for the int, but
that is a really minor invariant to try to preserve at the cost of loss
of regularity of the type. Yet another annoyance of the particular C++
object / move semantic model.
llvm-svn: 277582
manager.
While this has some utility for debugging and testing on its own, it is
primarily intended to demonstrate the technique for adding custom
wrappers that can provide more interesting interation behavior in
a nice, orthogonal, and composable layer.
Being able to write these kinds of very dynamic and customized controls
for running passes was one of the motivating use cases of the new pass
manager design, and this gives a hint at how they might look. The actual
logic is tiny here, and most of this is just wiring in the pipeline
parsing so that this can be widely used.
I'm adding this now to show the wiring without a lot of business logic.
This is a precursor patch for showing how a "iterate up to N times as
long as we devirtualize a call" utility can be added as a separable and
composable component along side the CGSCC pass management.
Differential Revision: https://reviews.llvm.org/D22405
llvm-svn: 277581
Summary:
We also add a test to show what currently happens when we create a
section per function and emit an xray_instr_map. This illustrates the
relationship (or lack thereof) between the per-function section and the
xray_instr_map section.
We also change the code generation slightly so that we don't always
create group sections, but rather only do so if a function where the
table is associated with is in a group.
Also in this change:
- Remove the "merge" flag on the xray_instr_map section.
- Test that we're generating the right table for comdat and non-comdat functions.
Reviewers: echristo, majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D23104
llvm-svn: 277580
Summary:
This code got landed and it's a mistake.
I suspect an incorrect patch was uploaded/applied.
The folders seems to be created here:
https://reviews.llvm.org/D23018
Reviewers: rnk
Subscribers: llvm-commits, chrisha, kcc
Differential Revision: https://reviews.llvm.org/D23109
llvm-svn: 277579
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.src/tools/clang/tools/extra/clang-tidy/mpi/TypeMismatchCheck.cpp:172:12: warning: parameter 'Complex' not found in the function declaration [-Wdocumentation]
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.src/tools/clang/tools/extra/clang-tidy/mpi/TypeMismatchCheck.cpp:206:12: warning: parameter 'Complex' not fo
llvm-svn: 277578
alexfh raised a concern with https://reviews.llvm.org/rL277340
After retabbing indentation of .. code-block:: was increased to 8, 4 spaces
indentation should be enough.
Reviewers: alexfh
llvm-svn: 277577
Summary:
The append operator on a shell command for quick command-line is
causing trouble on windows. [NFC]
The easiest way to fix them is to avoid using them.
This patch is an attempt to fix this broken build bot:
clang-x86-win2008-selfhost
http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/9523
Reviewers: rnk
Subscribers: cfe-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23105
llvm-svn: 277576
IfConversion used to always add the undef flag when adding a use operand
on a newly predicated instruction. This would be an operand for the register
being conditionally redefined. Due to the undef flag, the liveness of this
register prior to the predicated instruction would get lost.
This patch changes this so that such use operands are added only when the
register is live, without the undef flag.
This was reverted but pushed again now, for details follow link below.
Reviewed by Quentin Colombet.
http://reviews.llvm.org/D209077
llvm-svn: 277571
Mergeable sections with size zero are useless because they don't
actually contain data, and therefore there's no merit ot merge them.
However, in reality, there are object files in the wild containing
such sections. Currently, LLD can't handle them proerply.
This patch makes LLD to handle such sections as if they are non-
mergeable to fix the issue.
Fixes bug 28822.
llvm-svn: 277568
Summary:
This is the first refactoring before adding new functionality.
Add a class wrapper for the functions and container for
state associated with the transformation.
No functional change
Reviewers: majnemer, nadav, mehdi_amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23065
llvm-svn: 277565
I forgot to do this initially, and added when I saw this fail in
a no-asserts build, but managed to loose the diff from the actual patch
that got submitted. Very sorry.
llvm-svn: 277562
reason about and less error prone.
The core idea is to fully parse the text without trying to identify
passes or structure. This is done with a single state machine. There
were various bugs in the logic around this previously that were repeated
and scattered across the code. Having a single routine makes it much
easier to fix and get correct. For example, this routine doesn't suffer
from PR28577.
Then the actual pass construction is handled using *much* easier to read
code and simple loops, with particular pass manager construction sunk to
live with other pass construction. This is especially nice as the pass
managers *are* in fact passes.
Finally, the "implicit" pass manager synthesis is done much more simply
by forming "pre-parsed" structures rather than having to duplicate tons
of logic.
One of the bugs fixed by this was evident in the tests where we accepted
a pipeline that wasn't really well formed. Another bug is PR28577 for
which I have added a test case.
The code is less efficient than the previous code but I'm really hoping
that's not a priority. ;]
Thanks to Sean for the review!
Differential Revision: https://reviews.llvm.org/D22724
llvm-svn: 277561
Summary:
This patch is fixing a broken unittest which make the win64 bot failing.
The bug was introduce here:
https://reviews.llvm.org/D23046
The interception code is not the same in 32-bit and in 64-bit.
The added unittest can only be patched on 32-bits.
Reviewers: rnk
Subscribers: llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23099
llvm-svn: 277560
This fixes a bug where we'd sometimes cache overly-conservative results
with our walker. This bug was made more obvious by r277480, which makes
our cache far more spotty than it was. Test case is llvm-unit, because
we're likely going to use CachingWalker only for def optimization in the
future.
The bug stems from that there was a place where the walker assumed that
`DefNode.Last` was a valid target to cache to when failing to optimize
phis. This is sometimes incorrect if we have a cache hit. The fix is to
use the thing we *can* assume is a valid target to cache to. :)
llvm-svn: 277559
In r235779, Timur bumped the buffer size up to 1<<27, or about 134
million coverage points, presumably to handle Chrome. We allocate two
arrays of uptrs with this size, and this reliably exhausts all available
address space on 32-bit Windows (2 allocations of 512MB) when ASan is
also enabled.
Let's reduce the buffer size for now to stabilize the test suite. We can
re-evaluate the approach later when we've brought the Chrome ASan
builders back to life.
Kostya said that Mike reduced the number of instrumented coverage points
that LLVM emits by half since Timur made this change, so reducing this
array size should also be safe.
With this change, the 32-bit ASan tests reliably pass for me on Windows
10.
llvm-svn: 277558
Summary:
Sometimes, bitsets could get really large (>300k entries) and
we might want to drop a check, as it would have a too much cost.
Adding a flag to control how much penalty are we willing to pay
for bitsets.
Reviewers: kcc
Differential Revision: https://reviews.llvm.org/D23088
llvm-svn: 277556
Move those two options to llc:
The options in CommandFlags.h are shared by dsymutil, gold, llc,
llvm-dwp, llvm-lto, llvm-mc, lto, opt.
-stop-after/-start-after only affect codegen passes however only gold and llc
actually create codegen passes and I believe these flags to be only
useful for users of llc. For the other tools they are just highly
confusing: -stop-after claims to "Stop compilation after a specific
pass" which is not true in the context of the "opt" tool.
Differential Revision: https://reviews.llvm.org/D23050
llvm-svn: 277551
Correct two comments that do not match the current behavior of the checker.
A patch by Alexander Droste!
Differential Revision: https://reviews.llvm.org/D22670
llvm-svn: 277547
I examined a few PDBs and all of them treated pages for stream 0
are unused, thus they were unmarked in their free page bitmap.
I think we should do the same thing for compatibility.
Differential Revision: https://reviews.llvm.org/D23047
llvm-svn: 277545
In this particular example we wouldn't want the smmls anyway (the value is
actually unused), but in general smmls does not provide the required flags
register so if that SUBE result is used we can't replace it.
llvm-svn: 277541