When symbolizing large binaries, parsing every CU in a DWP file is a
significant performance penalty. Instead, use the index to only load the
CUs that are needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313659 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Fix the bug when promoted call return type mismatches with the promoted function, we should not try to inline it. Otherwise it may lead to compiler crash.
Reviewers: davidxl, tejohnson, eraman
Reviewed By: tejohnson
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D38018
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313658 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts r313431 and brings back r313374 with a fix to write
checksums as binary data and not ASCII hex strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313657 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for the R_AARCH64_ABS{16,32} relocations in the execution
engine. This is primarily used for DWARF debug information relocations
and needed by the LLVM JIT to support JITing for lldb.
Patch by Alex Langford!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313654 91177308-0d34-0410-b5e6-96231b3b80d8
The introduction of parameterized register classes in r313271 caused the
matcher generation code in TableGen to run much slower, particularly so
in the unoptimized (debug) build. This patch recovers some of the lost
performance.
Summary of changes:
- Cache the set of legal types in TypeInfer::getLegalTypes. The contents
of this set do not change.
- Add LLVM_ATTRIBUTE_ALWAYS_INLINE to several small functions. Normally
this would not be necessary, but in the debug build TableGen is not
optimized, so this helps a little bit.
- Add an early exit from TypeSetByHwMode::operator== for the case when
one or both arguments are "simple", i.e. only have one mode. This
saves some time in GenerateVariants.
- Finally, replace the underlying storage type in TypeSetByHwMode::SetType
with MachineValueTypeSet based on std::array instead of std::set.
This significantly reduces the number of memory allocation calls.
I've done a number of experiments with the underlying type of InfoByHwMode.
The type is a map, and for targets that do not use the parameterization,
this map has only one entry. The best (unoptimized) performance, somewhat
surprisingly came from std::map, followed closely by std::unordered_map.
DenseMap was the slowest by a large margin.
Various hand-crafted solutions (emulating enough of the map interface
not to make sweeping changes to the users) did not yield any observable
improvements.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313647 91177308-0d34-0410-b5e6-96231b3b80d8
After speaking with the libcxx owners, they agreed that this is
a bug in the bot that needs to be fixed by the bot owners, and
the CMake changes are correct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313643 91177308-0d34-0410-b5e6-96231b3b80d8
I forgot to zero out the BitVector when reusing it between UserValues.
Later uses of the same location number for a different UserValue would
falsely indicate that they were spilled. Usually this would lead to
incorrect debug info, but in some cases they would indicate something
nonsensical like a memory location based on a vector register (Q8 on
ARM).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313640 91177308-0d34-0410-b5e6-96231b3b80d8
Two blocks prior to the join each perform an li and the the join block has an
add using the initialized register. Optimize each predecessor block to instead
use addi and delete the li's and add.
Differential Revision: https://reviews.llvm.org/D36734
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313639 91177308-0d34-0410-b5e6-96231b3b80d8
The following 8 instructions are implemented in this patch.
addpcis(subpcis, lnia), darn, maddhd, maddhdu, maddld, setb
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313636 91177308-0d34-0410-b5e6-96231b3b80d8
This speeds up dumping specific DIEs by not parsing abbreviations for
units that are not used.
(this is also handy to have in eventually to speed up llvm-symbolizer
for .dwp files, where parsing most of the DWP file can be avoided by
using the index)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313635 91177308-0d34-0410-b5e6-96231b3b80d8
This is the second minimal patch keeping Nios2 target buildable.
I'm adding subtarget here and other stuff for frame lowering, instruction,
register information methods. I do not add any test cases, as still there
are missing parts like DAG selector and assembly printing. I plan to include
them into the next patch.
Patch by Andrei Grischenko <andrei.l.grischenko@intel.com>
Differential Revision: https://reviews.llvm.org/D37256
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313626 91177308-0d34-0410-b5e6-96231b3b80d8
This is a preparatory step for D34515.
This change:
- makes nodes ISD::ADDCARRY and ISD::SUBCARRY legal for i32
- lowering is done by first converting the boolean value into the carry flag
using (_, C) ← (ARMISD::ADDC R, -1) and converted back to an integer value
using (R, _) ← (ARMISD::ADDE 0, 0, C). An ARMISD::ADDE between the two
operations does the actual addition.
- for subtraction, given that ISD::SUBCARRY second result is actually a
borrow, we need to invert the value of the second operand and result before
and after using ARMISD::SUBE. We need to invert the carry result of
ARMISD::SUBE to preserve the semantics.
- given that the generic combiner may lower ISD::ADDCARRY and
ISD::SUBCARRYinto ISD::UADDO and ISD::USUBO we need to update their lowering
as well otherwise i64 operations now would require branches. This implies
updating the corresponding test for unsigned.
- add new combiner to remove the redundant conversions from/to carry flags
to/from boolean values (ARMISD::ADDC (ARMISD::ADDE 0, 0, C), -1) → C
- fixes PR34045
- fixes PR34564
Differential Revision: https://reviews.llvm.org/D35192
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313618 91177308-0d34-0410-b5e6-96231b3b80d8
The relocations used for externally visible functions
aren't supported, so the direct call emitted ends
up hitting a linker error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313616 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the instruction scheduling information for the SkylakeClient (SKL) architecture target by adding the file X86SchedSkylakeClient.td located under the X86 Target.
We used the scheduling information retrieved from the Skylake architects in order to create the file.
The scheduling information includes latency, number of micro-Ops and used ports by each SKL instruction.
The patch continues the scheduling replacement and insertion effort started with the SNB target in r307529 and r310792 and for HSW in r311879.
Please expect some performance fluctuations due to code alignment effects.
Reviewers: craig.topper, zvi, chandlerc, igorb, aymanmus, RKSimon, delena
Differential Revision: https://reviews.llvm.org/D37294
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313613 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9.
There is a bot that is checking out libcxx and lit with nothing
else and then running lit.py against the test tree. Since there's
no LLVM source tree, there's no LLVM CMake. CMake actually
reports this as a warning saying unsupported libcxx configuration,
but I guess someone is depending on it anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313607 91177308-0d34-0410-b5e6-96231b3b80d8
Move logic that allows for Triple deduction from an ObjectFile object
out of llvm-objdump.cpp into a public factory, found in the ObjectFile
class.
This should allow other tools in the future to use this logic without
reimplementation.
Patch by Mitch Phillips
Differential Revision: https://reviews.llvm.org/D37719
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313605 91177308-0d34-0410-b5e6-96231b3b80d8
Use the same logic as the line-oriented coverage view to determine the
number of covered lines in a function.
Fixes llvm.org/PR34615.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313604 91177308-0d34-0410-b5e6-96231b3b80d8
After clang started emitting deferred regions (r312818), llvm-cov has
had a hard time picking reasonable line execuction counts. There have
been one or two generic improvements in this area (e.g r310012), but
line counts can still report coverage for whitespace instead of code
(llvm.org/PR34612).
To fix the problem:
* Introduce a new region kind so that frontends can explicitly label
gap areas.
This is done by changing the encoding of the columnEnd field of
MappingRegion. This doesn't substantially increase binary size, and
makes it easy to maintain backwards-compatibility.
* Don't set the line count to a count from a gap area, unless the count
comes from a wrapped segment.
* Don't highlight gap areas as uncovered.
Fixes llvm.org/PR34612.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313597 91177308-0d34-0410-b5e6-96231b3b80d8
The checks with the MARKER prefix were not being run over the right
input, because stderr was not redirected properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313596 91177308-0d34-0410-b5e6-96231b3b80d8
Now that that segment builder is guaranteed to produce segments in
sorted order, we don't need a linear scan to get the right result.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313595 91177308-0d34-0410-b5e6-96231b3b80d8
Since the path a user specifies to the llvm-lit script might be
different than the source tree they built from (since they could
be behind different symlinks), we need to use realpath to make
sure that path comparisons work as expected.
Even better would be to use a custom dictionary comparison with
actual file equivalence comparison semantics, but this is the
least friction to unbreak things for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313594 91177308-0d34-0410-b5e6-96231b3b80d8
This caused asserts in Chromium. See http://crbug.com/766261
> Summary:
> This comes up in optimized debug info for C++ programs that pass and
> return objects indirectly by address. In these programs,
> llvm.dbg.declare survives optimization, which causes us to emit indirect
> DBG_VALUE instructions. The fast register allocator knows to insert
> DW_OP_deref when spilling indirect DBG_VALUE instructions, but the
> LiveDebugVariables did not until this change.
>
> This fixes part of PR34513. I need to look into why this doesn't work at
> -O0 and I'll send follow up patches to handle that.
>
> Reviewers: aprantl, dblaikie, probinson
>
> Subscribers: qcolombet, hiraditya, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D37911
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313589 91177308-0d34-0410-b5e6-96231b3b80d8
NFC intended here, this only updates clang and lld's lit configs
to use some helper functionality in the lit.llvm submodule.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313579 91177308-0d34-0410-b5e6-96231b3b80d8
If we have an AssertZext of a truncated value that has already been AssertZext'ed,
we can assert on the wider source op to improve the zext-y knowledge:
assert (trunc (assert X, i8) to iN), i1 --> trunc (assert X, i1) to iN
This moves a fold from being Mips-specific to general combining, and x86 shows
improvements.
Differential Revision: https://reviews.llvm.org/D37017
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313577 91177308-0d34-0410-b5e6-96231b3b80d8
