Summary:
While implementing atomicrmw in https://reviews.llvm.org/D40092 I found that
inheritance is unusable for all the Generic Opcodes in GlobalISel. This is
because the whole header is included inside a 'let mayLoad = 0, mayStore = 0 ... in'
block. In TableGen, the order of precedence for field assignments is:
1. Values from classes the record inherits from.
2. Values from 'let Name=Value in { ... }'
3. Values from 'let Name=Value;'
As such the 'let mayLoad = 0, mayStore = 0, ... in' surrounding the
'include "GenericOpcodes.td"' was overriding any values provided via inheritance.
We hadn't noticed this before because we were only using 'let Name=Value;' to
specialize opcodes.
Fix this by moving the default values to the lowest precedence. This is
accomplished by moving the values to a common base class
(StandardPseudoInstruction for most TargetOpcodes, and GenericOpcode for
GlobalISel specific TargetOpcodes)
Reviewers: qcolombet
Reviewed By: qcolombet
Subscribers: llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D40096
llvm-svn: 319701
Though it is incorrect from point of view of OpenMP standard to have
dependent iteration space in OpenMP loops, compiler should not crash.
Patch fixes this problem.
llvm-svn: 319700
Set the .debug_line version to match the requested DWARF version,
except with a maximum of v4 because we don't support v5 yet.
Previously Chromium had issues with this patch; see PR31407. Chromium
tool issues have been addressed, so hopefully this will go through
this time.
Patch by Katya Romanova!
Differential Revision: https://reviews.llvm.org/D38002
llvm-svn: 319699
Two copies of getSymLERange in RangeConstraintManager are virtually
identical, which is clearly bad.
This patch uses lambdas to call one from another (assuming that we would
like to avoid getting ranges from the state when necessary).
Differential Revision: https://reviews.llvm.org/D39709
llvm-svn: 319697
MatchRotate assumes the types of the types of LHS and RHS are equal,
which is always the case then they come from an OR node, but here
we're getting them from two different TRUNC nodes, so we have to check
the types.
llvm-svn: 319695
If the truncation has been pushed past the or-node, look through it and
truncate afterwards.
Differential revision: https://reviews.llvm.org/D40792
llvm-svn: 319692
This patch splits atomics out of the generic G_LOAD/G_STORE and into their own
G_ATOMIC_LOAD/G_ATOMIC_STORE. This is a pragmatic decision rather than a
necessary one. Atomic load/store has little in implementation in common with
non-atomic load/store. They tend to be handled very differently throughout the
backend. It also has the nice side-effect of slightly improving the common-case
performance at ISel since there's no longer a need for an atomicity check in the
matcher table.
All targets have been updated to remove the atomic load/store check from the
G_LOAD/G_STORE path. AArch64 has also been updated to mark
G_ATOMIC_LOAD/G_ATOMIC_STORE legal.
There is one issue with this patch though which also affects the extending loads
and truncating stores. The rules only match when an appropriate G_ANYEXT is
present in the MIR. For example,
(G_ATOMIC_STORE (G_TRUNC:s16 (G_ANYEXT:s32 (G_ATOMIC_LOAD:s16 X))))
will match but:
(G_ATOMIC_STORE (G_ATOMIC_LOAD:s16 X))
will not. This shouldn't be a problem at the moment, but as we get better at
eliminating extends/truncates we'll likely start failing to match in some
cases. The current plan is to fix this in a patch that changes the
representation of extending-load/truncating-store to allow the MMO to describe
a different type to the operation.
llvm-svn: 319691
Summary:
Move splitIndirectCriticalEdges() from CodeGenPrepare to BasicBlockUtils.h so
that it can be called from other places.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40750
llvm-svn: 319689
Summary:
preliminary design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer
The name TaggedAddressSanitizer and the rest of the document, are early draft, suggestions are welcome.
The code will follow shortly.
Reviewers: eugenis, alekseyshl
Reviewed By: eugenis
Subscribers: davidxl, cryptoad, fedor.sergeev, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D40568
llvm-svn: 319684
Follow-up of r316824. This patch supports the vector type for both current and
previous index when factoring out the current one into the previous one.
Differential Revision: https://reviews.llvm.org/D39556
llvm-svn: 319683
Summary:
To be more portable (especially w.r.t. platforms without system()),
commands should be managed programmatically rather than via string
manipulation on the command line. This change introduces
Fuzzer::Command, with methods to manage arguments and flags, set output
options, and execute the command.
Patch By: aarongreen
Reviewers: kcc, morehouse
Reviewed By: kcc, morehouse
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D40103
llvm-svn: 319680
Summary:
I don't think rL309080 is the right fix for PR33494 -- caching ExitLimit only
hides the problem[0]. The real issue is that because of how we forget SCEV
expressions ScalarEvolution::getBackedgeTakenInfo, in the test case for PR33494
computing the backedge for any loop invalidates the trip count for every other
loop. This effectively makes the SCEV cache useless.
I've instead made the SCEV expression invalidation in
ScalarEvolution::getBackedgeTakenInfo less aggressive to fix this issue.
[0]: One way to think about this is that rL309080 essentially augmented the
backedge-taken-count cache with another equivalent exit-limit cache. The bug
went away because we were explicitly not clearing the exit-limit cache in
getBackedgeTakenInfo. But instead of doing all of that, we can just avoid
clearing the backedge-taken-count cache.
Reviewers: mkazantsev, mzolotukhin
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D39361
llvm-svn: 319678
(This reapplies r314253. r314253 was reverted on r314482 because of a
correctness regression on P100, but that regression was identified to be
something else.)
Summary:
Don't bail out on constant divisors for divisions that can be narrowed without
introducing control flow . This gives us a 32 bit multiply instead of an
emulated 64 bit multiply in the generated PTX assembly.
Reviewers: jlebar
Subscribers: jholewinski, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D38265
llvm-svn: 319677
Summary:
This is an attempt at making `PopulateFreeArray` less obscure, more consistent,
and a tiny bit faster in some circumstances:
- use more consistent variable names, that work both for the user & the metadata
portions of the code; the purpose of the code is mostly the same for both
regions, so it makes sense that the code should be mostly similar as well;
- replace the while sum loops with a single `RoundUpTo`;
- mask most of the metadata computations behind kMetadataSize, allowing some
blocks to be completely optimized out if not use metadata;
- `const` the constant variables;
- add a `LIKELY` as the branch it applies to will almost always be taken.
Reviewers: alekseyshl, flowerhack
Reviewed By: alekseyshl
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D40754
llvm-svn: 319673
Following patch adds support of all memory origins in
CheckForInvalidPointerPair function. For small difference of pointers,
it's directly done in shadow memory (the limit was set to 2048B).
Then we search for origin of first pointer and verify that the second
one has the same origin. If so, we verify that it points either to a same
variable (in case of stack memory or a global variable), or to a same
heap segment.
Committing on behanf of marxin and jakubjelinek.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits
Differential revision: https://reviews.llvm.org/D40600
llvm-svn: 319668
Summary:
We want to automatically copy the appropriate mailing list
for review requests to the libc++ repository.
For context, see the proposal and discussion here:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/056032.html
Similar to D40179, I set up a new Diffusion repository with callsign
"CXX" for libc++:
https://reviews.llvm.org/source/libcxx/
This explicitly updates libcxx's .arcconfig to point to the new
CXX repository in Diffusion, which will let us use Herald rule H268.
Reviewers: halyavin, EricWF, mclow.lists, compnerd, mstorsjo
Reviewed By: compnerd
Subscribers: cfe-commits, bkramer, dlj, sammccall, klimek, smeenai, mstorsjo, krytarowski
Differential Revision: https://reviews.llvm.org/D40500
llvm-svn: 319666
As part of the unification of the debug format and the MIR format, print
MBB references as '%bb.5'.
The MIR printer prints the IR name of a MBB only for block definitions.
* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g'
* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g'
* find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g'
* grep -nr 'BB#' and fix
Differential Revision: https://reviews.llvm.org/D40422
llvm-svn: 319665
Summary:
The compiler fails with the following error message:
fatal error: error in backend: ran out of registers during
register allocation
Tail call optimization for Armv8-M.base fails to meet all the required
constraints when handling calls to function pointers where the
arguments take up r0-r3. This is because the pointer to the
function to be called can only be stored in r0-r3, but these are
all occupied by arguments. This patch makes sure that tail call
optimization does not try to handle this type of calls.
Reviewers: chill, MatzeB, olista01, rengolin, efriedma
Reviewed By: olista01, efriedma
Subscribers: efriedma, aemerson, javed.absar, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D40706
llvm-svn: 319664
This reverts commit r319533 as it broke llvm-config --system-libs output
and everything that depends on it (which is mostly out of tree or
downstream folks, but includes a couple of llvm buildbots as well).
I think I have a fix for this in D40779, but I want someone to look
review it first. In the mean time, I am reverting this change, as it
seems to break a lot of people.
llvm-svn: 319663
Summary:
Currently, we only support predication for forward loops with step
of 1. This patch enables loop predication for reverse or
countdownLoops, which satisfy the following conditions:
1. The step of the IV is -1.
2. The loop has a singe latch as B(X) = X <pred>
latchLimit with pred as s> or u>
3. The IV of the guard is the decrement
IV of the latch condition (Guard is: G(X) = X-1 u< guardLimit).
This patch was downstream for a while and is the last series of patches
that's from our LP implementation downstream.
Reviewers: apilipenko, mkazantsev, sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40353
llvm-svn: 319659
PTX requires that identifiers consist only of [a-zA-Z0-9_$]. The
existing pass already ensured this for globals and this patch adds
the cleanup for functions with local linkage.
However, there was a different problem in the case of collisions
of the adjusted name: The ValueSymbolTable then automatically
appended ".N" with increasing Ns to get a unique name while helping
the ABI demangling. Special case this behavior to omit the dots and
append N directly. This will always give us legal names according
to the PTX requirements.
Differential Revision: https://reviews.llvm.org/D40573
llvm-svn: 319657
The variable named `minor` was actually pointing to the patch part of
the version. While I was changing this I also made the check for Apple
clang more robust by checking both patch and minor rather than just
minor.
llvm-svn: 319656
Summary: Shared details of ClangdUnit and CodeComplete moved to a new Compiler file.
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40719
llvm-svn: 319655
This is causing a failure in the llvm-clang-x86_64-expensive-checks-win
buildbot, and I can't reproduce it locally, so reverting until I can work out
what is wrong.
llvm-svn: 319654
Summary:
This flag is on by default for darwin and freebsd, but off for linux.
Without it, clang will sometimes not emit debug info for types like
std::string. Whether it does this, and which tests will fail because of
that depends on the linux distro and c++ library version.
A bunch of tests were already setting these flags manually, but here
instead I take a whole sale approach and enable this flag for all tests.
Any test which does not want to have this flag (right now we have one
such test) can turn it off explicitly via
CFLAGS_EXTRAS+=$(LIMIT_DEBUG_INFO_FLAGS)
This fixes a bunch of data formatter tests on red-hat.
Reviewers: davide, jankratochvil
Subscribers: emaste, aprantl, krytarowski, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D40717
llvm-svn: 319653
Summary:
The pass that inserts s_waitcnt instructions where needed propagated
info used to track dependencies for each block by iterating over the
predecessor blocks. The iteration was terminated when a predecessor
that had not yet been processed was encountered. Any info in blocks
later in the list was therefore not processed, leading to the
possiblility of a required s_waitcnt not being inserted.
The fix is simply to change the "break" to "continue" for the
relevant loops, so that all visited blocks are processed. This
is likely what was intended when the code was written.
There is no test case provided for this fix because:
1) the only example that reproduces this is large and resistant to
being reduced
2) the change is trivial
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye
Differential Revision: https://reviews.llvm.org/D40544
llvm-svn: 319651
Summary:
The low-fat STL-like vector container will be reused in MSan.
It is needed to implement an atexit(3) interceptor on NetBSD/amd64 in MSan.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, dvyukov, eugenis, vitalybuka, kcc
Reviewed By: dvyukov
Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40726
llvm-svn: 319650
