r307367 via D34345 split out the temporary address state used within
processCommands() and assignAddresses(). Due to the way that getSymbolValue
is used by the ScriptParser there is no way of giving the current
OutputSection to getSymbolValue() without somehow accessing the created
addressState. The suggestion was that by making a pointer that would go out
of scope we would find out by ASAN/MSAN or a crash if someone had misused
currentAddressState.
Differential Revision: https://reviews.llvm.org/D34345
llvm-svn: 307637
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.
llvm-svn: 307634
Summary:
On linux on ppc64le some of the enums in AuxVector have the same name
as macros defined in the system.
Reviewers: mikesart, labath
Reviewed By: labath
Subscribers: joerg, gut, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D35065
Patch by Bruno Rosa <bruno.rosa@eldorado.org.br>
llvm-svn: 307632
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
llvm-svn: 307631
This is enough to link a working hello world executable, with
a call to an imported function, a string constant passed to
the imported function, and loads from a global variable.
Differential Revision: https://reviews.llvm.org/D34964
llvm-svn: 307629
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
llvm-svn: 307628
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.
llvm-svn: 307625
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
llvm-svn: 307624
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
llvm-svn: 307623
This is going to be used by the runtime build in the multi-target
setup to allow using different install prefix for each target.
Differential Revision: https://reviews.llvm.org/D33762
llvm-svn: 307615
This is going to be used by the runtime build in the multi-target
setup to allow using different install prefix for each target.
Differential Revision: https://reviews.llvm.org/D33761
llvm-svn: 307611
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
llvm-svn: 307610
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.
llvm-svn: 307609
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.
llvm-svn: 307608
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
llvm-svn: 307607
This is going to be used by the runtime build in the multi-target
setup to allow using different install prefix for each target.
Differential Revision: https://reviews.llvm.org/D33760
llvm-svn: 307606
This is a follow up for one of
the previous diffs https://reviews.llvm.org/D32328.
getTypeSize and with getIntWidth are not equivalent for bool
(see https://clang.llvm.org/doxygen/ASTContext_8cpp_source.html#l08444),
this causes a number of issues
(for instance, if APint X representing a bool is created
with the wrong bit width then X is not comparable against Min/Max
(because of the different bit width), that results in crashes
(triggered asserts) inside assume* methods),
for examples see the newly added test cases.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D35041
llvm-svn: 307604
I didn't commit clang-import-test.cpp in r307600, but it had some
changes that were part of https://reviews.llvm.org/D35220
Corrected that now.
llvm-svn: 307602
- eliminated error handling for the indirect CompilerInstance, which should
never generate an error as it is created;
- added a new test for direct importation; and
- removed an unused implementation of the CompleteType() API.
This brings clang-import-test.cpp and ExternalASTMerge.cpp back to 100%
coverage on all metrics measured by DLLVM_BUILD_INSTRUMENTED_COVERAGE.
Differential Revision: https://reviews.llvm.org/D35220
llvm-svn: 307600
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
llvm-svn: 307598
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!
llvm-svn: 307596
lld-link is apparently a symlink to lld. Our pdb writing code
uses llvm::sys::fs::getMainExecutable() and writes that value
into the PDB, which will resolve symlinks etc. But what we
really want is the exact value of argv[0], which matches what
the MS linker does. Fix this by just writing argv[0] instead
of calling getMainExecutable.
llvm-svn: 307592
Reverting as it breaks tramp3d-v4 in the llvm test-suite. I added some
comments to https://reviews.llvm.org/D33345 about it.
This reverts commit r307546.
llvm-svn: 307589
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
llvm-svn: 307587
Peter Smith