The earlier change added hotness attribute to missed-optimization
remarks. This follows up with the analysis remarks (the ones explaining
the reason for the missed optimization).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276192 91177308-0d34-0410-b5e6-96231b3b80d8
This helps because LoopAccessReport is passed around as a const
reference and we derive the basic block passed as the Value parameter
from the instruction in LoopAccessReport.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276191 91177308-0d34-0410-b5e6-96231b3b80d8
This adds an (incomplete, inefficient) framework for deciding what to do with
some operation on a given type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276184 91177308-0d34-0410-b5e6-96231b3b80d8
At -O0, cmpxchg survives AtomicExpand: it's mostly straightforward
to select it in fast-isel, and let the pseudo be expanded later.
extractvalues on the result are the tricky part: the generic logic
only works for legal types (and it would be painful to make it
support illegal types), so we can only support i32/i64 cmpxchg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276183 91177308-0d34-0410-b5e6-96231b3b80d8
We hoisted PHIs without respecting their special insertion point in the
block, leading to verfier errors.
This fixes PR28626.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276181 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously we wouldn't move loads/stores across instructions that had
side-effects, where that was defined as may-write or may-throw. But
this is not sufficiently restrictive: Stores can't safely be moved
across instructions that may load.
This patch also adds a DEBUG check that all instructions in our chain
are either loads or stores.
Reviewers: asbirlea
Subscribers: llvm-commits, jholewinski, arsenm, mzolotukhin
Differential Revision: https://reviews.llvm.org/D22547
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276171 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously if we had a chain that contained a side-effecting
instruction, we wouldn't vectorize it at all. Now we'll vectorize
everything that comes before the side-effecting instruction.
Reviewers: asbirlea
Subscribers: arsenm, jholewinski, llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D22536
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276170 91177308-0d34-0410-b5e6-96231b3b80d8
A seemingly common use for the walker's getClobberingMemoryAccess
function is:
```
MemoryAccess *getClobber(MemorySSAWalker *W, MemoryUseOrDef *MUD) {
const Instruction *I = MUD->getMemoryInst();
return W->getClobberingMemoryAccess(I);
}
```
Which is kind of redundant, since walkers will ultimately query MSSA to
find out which MemoryAccess `I` maps to (...which is always `MUD`).
So, this patch adds an overload of getClobberingMemoryAccess that
accepts MemoryAccesses directly. As a result, the Instruction overload
of getClobberingMemoryAccess becomes a lightweight wrapper around our
new overload.
Additionally, this patch un`virtual`izes the Instruction overload of
getClobberingMemoryAccess, since there doesn't seem to be a walker that
benefits from that being virtual, and I can't think of how else one
would implement it. Happy to make it virtual again if we would benefit
from doing so.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276169 91177308-0d34-0410-b5e6-96231b3b80d8
We can't guard the include of LowLevelType.h because getType and setType are
(trivial) functions even when GlobalISel isn't built.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276160 91177308-0d34-0410-b5e6-96231b3b80d8
This should be all the low-level instruction selection needs to determine how
to implement an operation, with the remaining context taken from the opcode
(e.g. G_ADD vs G_FADD) or other flags not based on type (e.g. fast-math).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276158 91177308-0d34-0410-b5e6-96231b3b80d8
Avoid unnecessary spills of byval arguments of device functions to
local space on SASS level and subsequent pointer conversion to generic
address space that follows. Instead, make a local copy in IR, provide
a way to access arguments directly, and let LLVM optimize the copy away
when possible.
Differential Review: https://reviews.llvm.org/D21421
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276153 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Mirroring most cleanup changed from compiler-rt/lib/builtins/cpu_model.
x86 methods are still returning a bool.
Reviewers: llvm-commits, echristo, craig.topper, sanjoy
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D22480
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276149 91177308-0d34-0410-b5e6-96231b3b80d8
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
S1 = S2 + C_a
S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276136 91177308-0d34-0410-b5e6-96231b3b80d8
Lots of blocks had "llvm" or "nasm" syntax types but either weren't following
the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type
doesn't even exist (nasm?).
Other documents had :options: what were invalid. I only removed those that had
warnings, and left the ones that didn't, in order to follow the principle of
least surprise.
This is like this for ages, but the buildbot is now failing on errors. It may
take a while to upgrade the buildbot's sphinx, if that's even possible, but
that shouldn't stop us from getting docs updates (which seem down for quite
a while).
Also, we're not losing any syntax highlight, since when it doesn't parse, it
doesn't colour. Ie. those blocks are not being highlighted anyway.
I'm trying to get all docs in one go, so that it's easy to revert later if we
do fix, or at least easy to know what's to fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276109 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: In r275989 we enabled the folding of `logic(cast(icmp), cast(icmp))` to `cast(logic(icmp, icmp))`. Here we add more test cases to assure this folding works for all logical operations `and`/`or`/`xor`.
Reviewers: grosser
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22561
Contributed-by: Matthias Reisinger
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276105 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds costs for the vectorized implementations of CTPOP, the default values were seriously underestimating the cost of these and was encouraging vectorization on targets where serialized use of POPCNT would be much better.
Differential Revision: https://reviews.llvm.org/D22456
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276104 91177308-0d34-0410-b5e6-96231b3b80d8
Retry r275776 (no changes, we suspect the issue was with another commit).
The current logic for handling inline asm operands in DAGToDAGISel interprets
the operands by looking for constants, which should represent the flags
describing the kind of operand we're dealing with (immediate, memory, register
def etc). The operands representing actual data are skipped only if they are
non-const, with the exception of immediate operands which are skipped explicitly
when a flag describing an immediate is found.
The oversight is that memory operands may be const too (e.g. for device drivers
reading a fixed address), so we should explicitly skip the operand following a
flag describing a memory operand. If we don't, we risk interpreting that
constant as a flag, which is definitely not intended.
Fixes PR26038
Differential Revision: https://reviews.llvm.org/D22103
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276101 91177308-0d34-0410-b5e6-96231b3b80d8
This will unblock the llvm-sphinx-buildbot, which is currently failing due
to a warning being treated as error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276100 91177308-0d34-0410-b5e6-96231b3b80d8
This document was crafted from the various (320+) emails between 2nd June and
20th July regarding the move to GitHub. It tried to consolidate every issue that
was raised and every solution that was presented to have a GitHub repository
with sub-modules.
It *does not* try to argue whether sub-modules are better or worse than any other
Git solution, nor if Git is better than any other VCS, nor if GitHub is better
than any other free code hosting service. This is just the final conclusions of
48 days and 320 emails (plus a lot of IRC discussions) on the LLVM community.
This document will be presented at the survey that the foundation will setup for
us to decide if we move to this solution or not. It reflects what was discussed
on the lists, but it's not authoritative. If something is not clear enough,
please refer to the mailing list discussions (hint: search for "GitHub").
Review: https://reviews.llvm.org/D22463
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276097 91177308-0d34-0410-b5e6-96231b3b80d8
Inference of the 'returned' attribute was fixed in r276008, lets try
turning the backend support back on.
This reverts commit r275677.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276081 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
getVectorizablePrefix previously didn't work properly in the face of
aliasing loads/stores. It unwittingly assumed that the loads/stores
appeared in the BB in address order. If they didn't, it would do the
wrong thing.
Reviewers: asbirlea, tstellarAMD
Subscribers: arsenm, llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D22535
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276072 91177308-0d34-0410-b5e6-96231b3b80d8
Reverting this commit for now as it seems to be causing failures on
test-suite tests on the clang-ppc64le-linux-lnt bot.
This reverts commit r276044.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276068 91177308-0d34-0410-b5e6-96231b3b80d8
Add a check that the layout predecessor of a block is an actual CFG
predecssor of the block as well. No current code fails this check, but
upcoming patches can trigger this, and it makes sense to separate it
out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276066 91177308-0d34-0410-b5e6-96231b3b80d8
