| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
became empty. This would manifest later as an assert failure due to
a non-empty list map but an empty result map. This doesn't easily
manifest with just the module pass manager and the function pass
manager, but the next commit will add the CGSCC pass manager that hits
this assert immediately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206744 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206741 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
break the API.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206740 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generating BZHI in the variable mask case, i.e. (and X, (sub (shl 1, N), 1)),
was already supported, but we were missing the constant-mask case. This patch
fixes that.
<rdar://problem/15480077>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206738 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
Original commit message:
Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN,
safe.srem.iN, safe.urem.iN (iN = i8, i61, i32, or i64).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206735 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206734 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
safe.urem.iN (iN = i8, i16, i32, or i64).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206732 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206730 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It could even be made non-virtual if it weren't for bad compiler
warnings.
This demonstrates that ArgList objects aren't destroyed polymorphically
and possibly that they aren't even used polymorphically. If that's the
case, it might be possible to refactor the two ArgList types more
separately and simplify the Arg ownership model. *continues
experimenting*
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206727 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
This might be able to be simplified further by using Arg as a value type
in a linked list (to maintain pointer validity), but here's something
simple to start with.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206724 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206723 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206722 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206721 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
and ContextDecision in different source files (depending on #define magic).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206720 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
different source files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206719 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
they need to...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206718 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
reason to expose a global symbol 'decodeInstruction' nor to pollute the global
scope with a bunch of external linkage entities (some of which conflict with
others elsewhere in LLVM).
This is just the initial transition to C++; more cleanups to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206717 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Cleanup only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206710 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Spotted by Nick Lewycky in review, thanks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206708 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
This reverts commit r206704, as expected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206707 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r206677, reapplying my BlockFrequencyInfo rewrite.
I've done a careful audit, added some asserts, and fixed a couple of
bugs (unfortunately, they were in unlikely code paths). There's a small
chance that this will appease the failing bots [1][2]. (If so, great!)
If not, I have a follow-up commit ready that will temporarily add
-debug-only=block-freq to the two failing tests, allowing me to compare
the code path between what the failing bots and what my machines (and
the rest of the bots) are doing. Once I've triggered those builds, I'll
revert both commits so the bots go green again.
[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445
<rdar://problem/14292693>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206704 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Win64 stack unwinder gets confused when execution flow "falls through" after
a call to 'noreturn' function. This fixes the "missing epilogue" problem by
emitting a trap instruction for IR 'unreachable' on x86_x64-pc-windows.
A secondary use for it would be for anyone wanting to make double-sure that
'noreturn' functions, indeed, do not return.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206684 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
http://reviews.llvm.org/D3422
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206683 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206678 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r206666, as planned.
Still stumped on why the bots are failing. Sanitizer bots haven't
turned anything up. If anyone can help me debug either of the failures
(referenced in r206666) I'll owe them a beer. (In the meantime, I'll be
auditing my patch for undefined behaviour.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206677 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206675 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
info for them. This isn't just a size/time saving, gcov may crash on these.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206671 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions for mov instructions instead of silently truncating by default.
For the ARM assembler, we want to avoid misleadingly allowing something
like "mov r0, <symbol>" especially when we turn it into a movw and the
expression <symbol> does not have a :lower16: or :upper16" as part of the
expression. We don't want the behavior of silently truncating, which can be
unexpected and lead to bugs that are difficult to find since this is an easy
mistake to make.
This does change the previous behavior of llvm but actually matches an
older gnu assembler that would not allow this but print less useful errors
of like “invalid constant (0x927c0) after fixup” and “unsupported relocation on
symbol foo”. The error for llvm is "immediate expression for mov requires
:lower16: or :upper16" with correct location information on the operand
as shown in the added test cases.
rdar://12342160
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206669 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r206628, reapplying r206622 (and r206626).
Two tests are failing only on buildbots [1][2]: i.e., I can't reproduce
on Darwin, and Chandler can't reproduce on Linux. Asan and valgrind
don't tell us anything, but we're hoping the msan bot will catch it.
So, I'm applying this again to get more feedback from the bots. I'll
leave it in long enough to trigger builds in at least the sanitizer
buildbots (it was failing for reasons unrelated to my commit last time
it was in), and hopefully a few others.... and then I expect to revert a
third time.
[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
[2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206666 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
describing it.
This is important for symbolizing executables with debug info in
unavailable .dwo files. Even if all DIE entries are missing, we can
still symbolize an address: function name can be fetched from symbol table,
and file/line info can be fetched from line table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206665 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206663 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
Both ZLIB and the debug info compressed section header ("ZLIB" + the
size of the uncompressed data) take some constant overhead so in some
cases the compressed data is actually larger than the uncompressed data.
In these cases, just don't compress or rename the section at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206659 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
This adds support for an indexed instrumentation based profiling
format, which is just a small header and an on disk hash table. This
format will be used by clang's -fprofile-instr-use= for PGO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206656 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
Immutable DILineInfo doesn't bring any benefits and complicates
code. Also, use std::string instead of SmallString<16> for file
and function names - their length can vary significantly.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206654 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While unnamed relocations are already cached in side tables in
ELFObjectWriter::RecordRelocation, symbols still need their fragments
updated to refer to the newly compressed fragment (even if that fragment
isn't big enough to fit the offset). Even though we only create
temporary symbols in debug info sections this comes up in 32 bit builds
where even temporary symbols in mergeable sections (such as debug_str)
have to be emitted as named symbols.
I tried a few other ways to do this but they all didn't work for various
reasons:
1) Canonicalize the MCSymbolData in RecordRelocation, nulling out the
Fragment (so it didn't have to be updated by CompressDebugSection). This
doesn't work because some code relies on symbols having fragments to
indicate that they're defined, I think.
2) Canonicalize the MCSymbolData in RecordRelocation to be "first
fragment + absolute offset" so it would be cheaper to just test and
update the fragment in CompressDebugSections. This doesn't work because
the offset computed in RecordRelocation isn't that of the symbol's
fragment, it's the passed in fragment (I haven't figured out what that
fragment is - perhaps it's the location where the relocation is to be
written). And if the fragment offset has to be computed only for this
use we might as well just do it when we need to, in
CompressDebugSection.
I also added an assert to help catch this a bit more clearly, even
though it is UB. The test case improvements would either assert fail
and/or valgrind vail without the fix, even if they wouldn't necessarily
fail the FileCheck output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206653 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This port includes the rudimentary latencies that were provided for
the Cortex-A53 Machine Model in the AArch64 backend. It also changes
the SchedAlias for COPY in the Cyclone model to an explicit
WriteRes mapping to avoid conflicts in other subtargets.
Differential Revision: http://reviews.llvm.org/D3427
Patch by Dave Estes <cestes@codeaurora.org>!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206652 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
caught). Sad that we don't have warnings for these things, but bleh, no
idea how to fix that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206646 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
When address ranges for compile unit are specified in compile unit DIE
itself, there is no need to collect ranges from children subprogram DIEs.
This change speeds up llvm-symbolizer on Clang-produced binaries with
full debug info. For instance, symbolizing a first address in a 1Gb binary
is now 2x faster (1s vs. 2s).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206635 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For a 256-bit BUILD_VECTOR consisting mostly of shuffles of 256-bit vectors,
both the BUILD_VECTOR and its operands may need to be legalized in multiple
steps. Consider:
(v8f32 (BUILD_VECTOR (extract_vector_elt (v8f32 %vreg0,) Constant<1>),
(extract_vector_elt %vreg0, Constant<2>),
(extract_vector_elt %vreg0, Constant<3>),
(extract_vector_elt %vreg0, Constant<4>),
(extract_vector_elt %vreg0, Constant<5>),
(extract_vector_elt %vreg0, Constant<6>),
(extract_vector_elt %vreg0, Constant<7>),
%vreg1))
a. We can't build a 256-bit vector efficiently so, we need to split it into
two 128-bit vecs and combine them with VINSERTX128.
b. Operands like (extract_vector_elt (v8f32 %vreg0), Constant<7>) needs to be
split into a VEXTRACTX128 and a further extract_vector_elt from the
resulting 128-bit vector.
c. The extract_vector_elt from b. is lowered into a shuffle to the first
element and a movss.
Depending on the order in which we legalize the BUILD_VECTOR and its
operands[1], buildFromShuffleMostly may be faced with:
(v4f32 (BUILD_VECTOR (extract_vector_elt
(vector_shuffle<1,u,u,u> (extract_subvector %vreg0, Constant<4>), undef),
Constant<0>),
(extract_vector_elt
(vector_shuffle<2,u,u,u> (extract_subvector %vreg0, Constant<4>), undef),
Constant<0>),
(extract_vector_elt
(vector_shuffle<3,u,u,u> (extract_subvector %vreg0, Constant<4>), undef),
Constant<0>),
%vreg1))
In order to figure out the underlying vector and their identity we need to see
through the shuffles.
[1] Note that the order in which operations and their operands are legalized is
only guaranteed in the first iteration of LegalizeDAG.
Fixes <rdar://problem/16296956>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206634 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206632 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
This reverts commit r206622 and the MSVC fixup in r206626.
Apparently the remotely failing tests are still failing, despite my
attempt to fix the nondeterminism in r206621.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206628 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206626 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206625 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
Add a helper method to get address ranges specified in a DIE
(either by DW_AT_low_pc/DW_AT_high_pc, or by DW_AT_ranges). Use it
to untangle and simplify the code.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r206556, effectively reapplying commit r206548 and
its fixups in r206549 and r206550.
In an intervening commit I've added target triples to the tests that
were failing remotely [1] (but passing locally). I'm hoping the mystery
is solved? I'll revert this again if the tests are still failing
remotely.
[1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206622 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Part of PR19455.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206611 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Part of PR19455.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206610 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206609 91177308-0d34-0410-b5e6-96231b3b80d8
|