Add explicit dependency on ObjcopyTableGen
and rerun the tests on Windows.
I will double-check the build bots
and revert this commit if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330685 91177308-0d34-0410-b5e6-96231b3b80d8
This encoding is recognized by the CPU, but the behavior is undefined. This makes the disassembler handle it correctly so we don't print bswapl with a 16-bit register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330682 91177308-0d34-0410-b5e6-96231b3b80d8
This code path can very clearly be called in a context where we have
baselined all the cloned blocks to a particular loop and are trying to
handle nested subloops. There is no harm in this, so just relax the
assert. I've added a test case that will make sure we actually exercise
this code path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330680 91177308-0d34-0410-b5e6-96231b3b80d8
The test is apparently needed e.g. for check-cfi on Windows where we get
'C:/b/slave/sanitizer-windows/build/./bin/clang.exe': command not found
without it. Try to fix the problem that was fixed by r330672 by also checking
for isabs() instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330673 91177308-0d34-0410-b5e6-96231b3b80d8
lit's util.which() would check if the passed-in path existed directly,
and if so return it as-is. This is never the case when running llvm's, clang's,
or lld's tests normally. But when running `./llvm-lit path/to/clang/test`
with a cwd of llvm-build/bin, this if would detect that clang exists at path
'clang' and return 'clang' as the discovered clang binary -- and then lit would
use the " clang " -> "*** Do not use 'clang' in tests, use '%clang'. ***"
substitution to replace that with a broken test. By removing this early
return, lit ends up with the usual absolute path and everything works even
in this uncommon case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330672 91177308-0d34-0410-b5e6-96231b3b80d8
(notionally Scalar.h is part of libLLVMScalarOpts, so it shouldn't be
included by InstCombine which doesn't/shouldn't need to depend on
ScalarOpts)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330669 91177308-0d34-0410-b5e6-96231b3b80d8
I was reminded today that this patch got reverted in r301885. I can no
longer reproduce the failure that caused the revert locally (...almost
one year later), and the patch applied pretty cleanly, so I guess we'll
see if the bots still get angry about it.
The original breakage was InstSimplify complaining (in "assertion
failed" form) about getting passed some crazy IR when running `ninja
check-sanitizer`. I'm unable to find traces of what, exactly, said crazy
IR was. I suppose we'll find out pretty soon if that's still the case.
:)
Original commit:
Author: gbiv
Date: Mon May 1 18:12:08 2017
New Revision: 301880
URL: http://llvm.org/viewvc/llvm-project?rev=301880&view=rev
Log:
[InstSimplify] Handle selects of GEPs with 0 offset
In particular (since it wouldn't fit nicely in the summary):
(select (icmp eq V 0) P (getelementptr P V)) -> (getelementptr P V)
Differential Revision: https://reviews.llvm.org/D31435
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330667 91177308-0d34-0410-b5e6-96231b3b80d8
As we're becoming stricter w/ respect to not allowing vregs having LLTs
and regclasses assigned both mid-globalisel pipeline, the number of
extra copies grows, some of which separate G_UNMERGE's from their
corresponding G_MERGE's, becoming a performance concern.
It's worth mentioning that we're already looking through copies while
combining legalization artifacts for every kind of artifact but
G_UNMERGE.
Reviewed By: aditya_nandakumar
Reviewers: ab, t.p.northover, volkan, javed.absar
Subscribers: rovka, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D45644
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330660 91177308-0d34-0410-b5e6-96231b3b80d8
If a loop with child loops becomes our new inner loop after
interchanging, we only need to update LoopInfo for the blocks defined in
the old outer loop. BBs in child loops will stay there.
Reviewers: efriedma, karthikthecool, mcrosier
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D45970
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330653 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is [[ https://bugs.llvm.org/show_bug.cgi?id=37104 | PR37104 ]].
[[ https://bugs.llvm.org/show_bug.cgi?id=6773 | PR6773 ]] will introduce an IR canonicalization that is likely bad for the end assembly.
Previously, `andl`+`andn`/`andps`+`andnps` / `bic`/`bsl` would be generated. (see `@out`)
Now, they would no longer be generated (see `@in`).
So we need to make sure that they are still generated.
If the mask is constant, we do nothing. InstCombine should have unfolded it.
Else, i use `hasAndNot()` TLI hook.
For now, only handle scalars.
https://rise4fun.com/Alive/bO6
----
I *really* don't like the code i wrote in `DAGCombiner::unfoldMaskedMerge()`.
It is super fragile. Is there something like IR Pattern Matchers for this?
Reviewers: spatel, craig.topper, RKSimon, javed.absar
Reviewed By: spatel
Subscribers: andreadb, courbet, kristof.beyls, javed.absar, rengolin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D45733
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330646 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is [[ https://bugs.llvm.org/show_bug.cgi?id=37104 | PR37104 ]].
[[ https://bugs.llvm.org/show_bug.cgi?id=6773 | PR6773 ]] will introduce an IR canonicalization that is likely bad for the end assembly.
Previously, `andl`+`andn`/`andps`+`andnps` / `bic`/`bsl` would be generated. (see `@out`)
Now, they would no longer be generated (see `@in`).
I'm guessing `llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp` should be able to unfold this.
Reviewers: spatel, craig.topper, RKSimon, javed.absar
Reviewed By: spatel
Subscribers: nemanjai, rengolin, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D45563
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330645 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith noted that `typedef typename iplist::iplist_impl_type
iplist_impl_type` is incorrect, per
http://eel.is/c++draft/basic.scope#class-2
It seems that neither clang nor gcc get too angry about this, but a
newer version of msvc does.
Thanks to jcmac on IRC for pointing this out!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330639 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Skip basic blocks not reachable from the entry node
in MemCpyOptPass::iterateOnFunction.
Code that is unreachable may have properties that do not exist
for reachable code (an instruction in a basic block can for
example be dominated by a later instruction in the same basic
block, for example if there is a single block loop).
MemCpyOptPass::processStore is only safe to use for reachable
basic blocks, since it may iterate past the basic block
beginning when used for unreachable blocks. By simply skipping
to optimize unreachable basic blocks we can avoid asserts such
as "Assertion `!NodePtr->isKnownSentinel()' failed."
in MemCpyOptPass::processStore.
The problem was detected by fuzz tests.
Reviewers: eli.friedman, dneilson, efriedma
Reviewed By: efriedma
Subscribers: efriedma, llvm-commits
Differential Revision: https://reviews.llvm.org/D45889
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330635 91177308-0d34-0410-b5e6-96231b3b80d8
This reland includes a check to prevent the DAG combiner from folding an
offset that is smaller than the existing one. This can cause oscillations
between two possible DAGs, which was the cause of the hang and later assertion
failure observed on the lnt-ctmark-aarch64-O3-flto bot.
http://green.lab.llvm.org/green/job/lnt-ctmark-aarch64-O3-flto/2024/
Original commit message:
> This is a code size win in code that takes offseted addresses
> frequently, such as C++ constructors that typically need to compute
> an offseted address of a vtable. This reduces the size of Chromium
> for Android's .text section by 108KB.
Differential Revision: https://reviews.llvm.org/D45199
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330630 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change teaches DSE that the atomic memory intrinsics are stores
that can be eliminated, and can allow other stores to be eliminated.
This change specifically does not teach DSE that these intrinsics
can be partially eliminated (i.e. length reduced, and dest/src changed);
that will be handled in another change.
Reviewers: mkazantsev, skatkov, apilipenko, efriedma, rsmith
Reviewed By: efriedma
Subscribers: dmgreen, llvm-commits
Differential Revision: https://reviews.llvm.org/D45535
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330629 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a cost model test case for vector shuffles having transpose
masks. The given costs are inaccurate and will be updated in a follow-on patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330625 91177308-0d34-0410-b5e6-96231b3b80d8
This demonstrates a bug where the encoding for a 16-bit bswap prints a 16-bit register and a 32-bit mnemonic. Intel docs say 16-bit bswap is undefined. We should either claim it as an invalid encoding or we should print a 16-bit mnemonic.
objdump does print the encoding as bswap with a 16-bit register. But it doesn't seem to ever print a suffix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330621 91177308-0d34-0410-b5e6-96231b3b80d8
Only add support for getSchedInfoStr(const MachineInstr &MI) at the TargetSubtargetInfo level.
Really, the getSchedInfoStr calls need to be removed entirely, we should just return a latency/rthroughput through the subtarget and keep a string creation helper function somewhere else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330615 91177308-0d34-0410-b5e6-96231b3b80d8
It's possible to validly spill the frame offset register
in a call sequence to a VGPR. There are definitely issues
with SGPR spilling to memory, so move the assert later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330612 91177308-0d34-0410-b5e6-96231b3b80d8
We use llvm-symbolizer in some production systems, and we run it
against all possibly related files, including some that are not
ELF. We noticed that for some of those invalid files, llvm-symbolizer
would crash with SEGFAULT. Here is an example of such a file.
It is due to that in computeSymbolSizes, a loop uses condition
for (unsigned I = 0, N = Addresses.size() - 1; I < N; ++I) {
where if Addresses.size() is 0, N would overflow and causing the loop
to access invalid memory.
Instead of patching the loop conditions, the commit makes so that the
function returns early if Addresses is empty.
Validated by checking that llvm-symbolizer no longer crashes.
Patch by Teng Qin!
Differential Revision: https://reviews.llvm.org/D44285
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330610 91177308-0d34-0410-b5e6-96231b3b80d8
Also assert that it is correct for SGPRs. There is currently a bug
where stack slot coloring replaces SGPR spill FIs with one with
the default ID, which results in a more confusing assert later
about a dead object.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330607 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This just refactors the lowering of the atomic memory intrinsics to more
closely match the code patterns used in the lowering of the non-atomic
memory intrinsics. Specifically, we encapsulate the lowering in
SelectionDAG::getAtomicMem*() functions rather than embedding
the code directly in the SelectionDAGBuilder code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330603 91177308-0d34-0410-b5e6-96231b3b80d8
