Use CHECK-NEXT for the comparison sequence, to make sure we don't get
any unexpected instructions in the middle of our flag manipulation
efforts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307656 91177308-0d34-0410-b5e6-96231b3b80d8
There were two errors in the parsing of opt's command line options for
extension point pipelines. The EP callbacks are not supposed to return a
value. To check the pipeline text for correctness, I now try to parse it
into a temporary PM object, and print a message on failure. This solves
the compile time error for the lambda return type, as well as correctly
handles unparsable pipelines now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307649 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure that all the legalizer tests where the original instruction
needs to be removed check for the removal. We do this by adding
CHECK-NOT lines before and after the replacement sequence. This won't
catch pathological cases where the instruction remains somewhere in the
middle of the instruction sequence that's supposed to replace it, but
hopefully that won't occur in practice (since ideally we'd be setting
the insert point for the new instruction sequence either before or after
the original instruction and not fiddle with it while building the
sequence).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307647 91177308-0d34-0410-b5e6-96231b3b80d8
In each rule, each use of ComplexPattern is assigned an element in the Renderers
array. The matcher then collects renderer functions in this array and they are
used to render instructions. This works well for a single instruction but a
bug in the allocation mechanism causes the elements to be assigned on a
per-instruction basis rather than a per-rule basis.
So in the case of:
(set GPR32:$dst, (Op complex:$src1, complex:$src2))
tablegen currently assigns elements 0 and 1 to $src1 and $src2 respectively,
but for:
(set GPR32:$dst, (Op complex:$src1, (Op complex:$src2)))
it currently assigned both $src1 and $src2 the same element (0). This results in
one complex operand being rendered twice and the other being forgotten.
This patch corrects the allocation such that $src1 and $src2 are still allocated
different elements in this case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307646 91177308-0d34-0410-b5e6-96231b3b80d8
This change allows the pc to be used as a destination register for the
pseudo instruction LDR pc,=expression . The pseudo instruction must not be
transformed into a MOV, but it can use the Thumb2 LDR (literal) instruction
to a constant pool entry. See (A7.7.43 from ARMv7M ARM ARM).
Differential Revision: https://reviews.llvm.org/D34751
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307640 91177308-0d34-0410-b5e6-96231b3b80d8
We used to forget to erase the original instruction when replacing a
G_FCMP true/false. Fix this bug and make sure the tests check for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307639 91177308-0d34-0410-b5e6-96231b3b80d8
TreePatternNode considers them to be plain integers but MachineInstr considers
them to be a distinct kind of operand.
The tweak to AArch64InstrInfo.td to produce a simple test case is a NFC for
everything except GlobalISelEmitter (confirmed by diffing the tablegenerated
files). GlobalISelEmitter is currently unable to infer the type of operands in
the Dst pattern from the operands in the Src pattern.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307634 91177308-0d34-0410-b5e6-96231b3b80d8
This is a second attempt to land this patch.
The first one resulted in a crash of clang sanitizer buildbot.
The fix is here and regression test is added.
This is a last fix for the corner case of PR32214. Actually this is not really corner case in general.
We should not do a loop rotation if we create an additional branch due to it.
Consider the case where we have a loop chain H, M, B, C , where
H is header with viable fallthrough from pre-header and exit from the loop
M - some middle block
B - backedge to Header but with exit from the loop also.
C - some cold block of the loop.
Let's H is determined as a best exit. If we do a loop rotation M, B, C, H we can introduce the extra branch.
Let's compute the change in number of branches:
+1 branch from pre-header to header
-1 branch from header to exit
+1 branch from header to middle block if there is such
-1 branch from cold bock to header if there is one
So if C is not a predecessor of H then we introduce extra branch.
This change actually prohibits rotation of the loop if both true
Best Exit has next element in chain as successor.
Last element in chain is not a predecessor of first element of chain.
Reviewers: iteratee, xur, sammccall, chandlerc
Reviewed By: iteratee
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34745
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307631 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenPrepare::optimizeMemoryInst contains a check that we do nothing
if all instructions combining the address for memory instruction is in the same
block as memory instruction itself.
However if any of these instruction are placed after memory instruction then
address calculation will not be folded to memory instruction.
The added test case shows an example.
Reviewers: loladiro, spatel, efriedma
Reviewed By: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34862
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307628 91177308-0d34-0410-b5e6-96231b3b80d8
querying for analysis results on a function declaration rather than
a definition.
The only reason this worked previously is by chance -- because the way
we got alias analysis results with the legacy PM, we happened to not
compute a dominator tree and so we happened to not hit an assert even
though it didn't make any real sense. Now we bail out before trying to
compute alias analysis so that we don't hit these asserts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307625 91177308-0d34-0410-b5e6-96231b3b80d8
In the POWER9 instruction scheduler, SchedWriteRes for the simple integer instructions are misconfigured to use that of (costly) DFU instructions.
This results in surprisingly long instruction latency estimation and causes misbehavior in some optimizers such as if-conversion.
Differential Revision: https://reviews.llvm.org/D34869
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307624 91177308-0d34-0410-b5e6-96231b3b80d8
This patch reduces compilation time by avoiding redundant analysis while selecting instructions to create an immediate.
If the instruction count required to create the input number without rotate is 2, we do not need further analysis to find a shorter instruction sequence with rotate; rotate + load constant cannot be done by 1 instruction (i.e. getInt64CountDirectnever return 0).
This patch should not change functionality.
Differential Revision: https://reviews.llvm.org/D34986
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307623 91177308-0d34-0410-b5e6-96231b3b80d8
PR30735 reports an issue where llvm-cov hangs with a worker thread
waiting on a condition, and the main thread waiting to join() the
workers. While this doesn't appear to be a bug in llvm-cov or the
ThreadPool implementation, it would be helpful to disable the use of
threading in the llvm-cov tests where no test coverage is added.
More context: https://bugs.llvm.org/show_bug.cgi?id=30735
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307610 91177308-0d34-0410-b5e6-96231b3b80d8
When an output directory is specified, llvm-cov spawns some threads to
speed up the process of writing out file reports. Add an option which
allows users to control how many threads llvm-cov uses.
A CommandGuide.rst update + test is included.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307609 91177308-0d34-0410-b5e6-96231b3b80d8
This takes memory usage from 5.1GB to 970MB - it could go further by
using a small size of 2 instead of the default of 4, but given the
rather high cost of going over this limit by much, I figured a little
slosh would be worth the ~130MB of memory usage.
& this'll might not be such a big deal if we use a custom slab allocator
for the DenseMaps here anyway
While the vast majority (99.9%) of records use only 1 entry, the tuning
parameter to SmallDenseMap is the the number of buckets, not the number
of entries - so a small size of 1 wasn't useful, even for 1 element, it
would tip over into allocating (much, 64 slots worth) more space - none
of them ended up small.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307608 91177308-0d34-0410-b5e6-96231b3b80d8
Haiku uses GNU ld for linking, but is not captured in the
conditional when setting LIB_NAMES. This causes a shared
library with no symbols on Haiku. This patch simply adds
a check for whether the CMake system name is Haiku in
addition to the existing checks.
Patch by Jérôme Duval.
Differential Revision: https://reviews.llvm.org/D34998
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307607 91177308-0d34-0410-b5e6-96231b3b80d8
This is part of the continuing effort to increase parity between
LLD and MSVC PDBs. link still doesn't like our PDBs, so the most
obvious thing to check was whether adding an empty publics stream
would get it to do something else. It still fails in the same way
but at least this removes one more variable from the equation.
The next logical step would be to try creating an empty globals
stream.
Differential Revision: https://reviews.llvm.org/D35224
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307598 91177308-0d34-0410-b5e6-96231b3b80d8
This unit test constructed some profile records incorrectly. One of the
records had a duplicate name: adding that record into the writer caused
an error unrelated to what needed to be tested.
Reported by David Blaikie!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307596 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
As metioned in https://reviews.llvm.org/D34576, checkings in
`collectConstantCandidates` can be replaced by using
`llvm::canReplaceOperandWithVariable`.
The only special case is that `collectConstantCandidates` return false for
all `IntrinsicInst` but it is safe for us to collect constant candidates from
`IntrinsicInst`.
Reviewers: pirama, efriedma, srhines
Reviewed By: efriedma
Subscribers: llvm-commits, javed.absar
Differential Revision: https://reviews.llvm.org/D34921
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307587 91177308-0d34-0410-b5e6-96231b3b80d8
For each checked-in wasm file, make sure the there is
corresponding .ll file that can be used to regenerate it
if needed.
Add test/Object/Inputs/trivial-object-test.wasm to match other
formats and add some new wasm tests in test/Object.
Differential Revision: https://reviews.llvm.org/D35213
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307585 91177308-0d34-0410-b5e6-96231b3b80d8
