Summary: The dbg.declare -> dbg.value conversion did not check which operand of
the store instruction the alloca was passed to. As a result code that stored the
address of an alloca, rather than storing to the alloca, would still trigger
the conversion routine, leading to the insertion of an incorrect dbg.value
intrinsic.
Reviewers: aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16169
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257787 91177308-0d34-0410-b5e6-96231b3b80d8
Coverage mapping data is not referenced by runtime, and they won't be dumped
into profile data. There is no need to allocate memory for covmap sections.
A good side effect of this change is that the coverage map data won't be mistakenly
garbage collected by the linker (for Gold linker only, BFD linker has an issue where the a bug is filed).
Tested with clang build with instrumentation and -fcoverage-mapping and linker GC. The size of
covmap section is ~17.6M so the text segment size will be reduced by this amount with this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257781 91177308-0d34-0410-b5e6-96231b3b80d8
These fields are almost always zero. However, there are relocations
against them, and we should print the relocation symbol with it as
SYM+0xNN.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257776 91177308-0d34-0410-b5e6-96231b3b80d8
Some patterns of select+compare allow us to know exactly the value of the uppermost bits in the select result. For example:
%b = icmp ugt i32 %a, 5
%c = select i1 %b, i32 2, i32 %a
Here we know that %c is bounded by 5, and therefore KnownZero = ~APInt(5).getActiveBits() = ~7.
There are several such patterns, and this patch attempts to understand a reasonable subset of them - namely when the base values are the same (as above), and when they are related by a simple (add nsw), for example (add nsw %a, 4) and %a.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257769 91177308-0d34-0410-b5e6-96231b3b80d8
Loop trip counts can often be resolved during LTO. We should obviously be unrolling small loops once those trip counts have been resolved, but we weren't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257767 91177308-0d34-0410-b5e6-96231b3b80d8
Phabricator to trunk.
The previous documentation had a few issues:
* It did not make it explicit that code could be
committed without using the Arcanist tool and how this should be done.
* There was also an implicit assumption on using Subversion
rather than git-svn in the example using Arcanist. The documentation now
explicitly mentions both cases and details how to commit to trunk in
each case.
Reviewers: klimek, probinson
Subscribers: probinson, nwilson, reames, llvm-commits
Differential Revision: http://reviews.llvm.org/D15801
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257764 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Since globals may escape as function arguments (even when they have been
found to be non-escaping, because of optimizations such as memcpyoptimizer
that replaces stores with memcpy), all arguments to a function are checked
during query to make sure they are identifiable. At that time, also ensure
we return a conservative result only if the arguments don't alias to our global.
Reviewers: hfinkel, jmolloy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16140
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257750 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The overloads of CallInst::Create and InvokeInst::Create that are used to
adjust operand bundles purport to create a new instruction "identical in
every way except [for] the operand bundles", so copy the DebugLoc along
with everything else.
Reviewers: sanjoy, majnemer
Subscribers: majnemer, dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D16157
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257745 91177308-0d34-0410-b5e6-96231b3b80d8
Binary annotations are encoded along the lines of UTF-8 and ECI but with
a few minor differences.
The algorithm specified in "ECMA-335 CLI Section II.3.2 - Blobs and
Signatures" is used to compress binary annotations. Signed binary
annotations are encoded like unsigned annotations except the sign bit is
rotated left to reduce the number of bits needed to be encoded.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257742 91177308-0d34-0410-b5e6-96231b3b80d8
A recent change introduced this assertion failure in some corner cases.
Repro:
mkdir /s/wasm/torture-out ; time /s/wasm/waterfall/src/compile_torture_tests.py --c /s/llvm/out/bin/clang --cxx /s/llvm/out/bin/clang++ --testsuite /s/gcc/gcc/testsuite --fails /s/llvm/llvm/lib/Target/WebAssembly/known_gcc_test_failures.txt --out /s/wasm/torture-out
Or look on the wasm integration bot:
https://build.chromium.org/p/client.wasm.llvm/console
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257733 91177308-0d34-0410-b5e6-96231b3b80d8
We rely on HasOpaqueSPAdjustment not changing after we've calculated
things based on it. Things like whether or not we can use 'rep;movs' to
copy bytes around, that sort of thing. If it changes, invariants in the
backend will quietly break. This situation arose when we had a call to
memcpy *and* a COPY of the FLAGS register where we would attempt to
reference local variables using %esi, a register that was clobbered by
the 'rep;movs'.
This fixes PR26124.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257730 91177308-0d34-0410-b5e6-96231b3b80d8
The only two Registries we have in the system are the GCStrategy and GCMetadataPrinter ones. Registry has a bunch of problems - for instance, order of initialization is undefined - and the code was overly general for what was actually used. I hope to completely kill Registry in the near future, but for now, just delete all the unused listener and parsing support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257727 91177308-0d34-0410-b5e6-96231b3b80d8
This code isn't reachable if the GFI (GCFunctionInfo*) is null. Clarify this by adding an assert and removing an always taken if.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257724 91177308-0d34-0410-b5e6-96231b3b80d8
Clang generates good display names for codeview since r255744, and the
change to make LLVM use them was accidentally included in r257658.
This change just updates the comments and test case to reflect reality
better.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257723 91177308-0d34-0410-b5e6-96231b3b80d8
platforms.
With ELF, the alignment of a global variable in a shared library will
get copied into an executables linked against it, if the executable even
accesss the variable. So, it's not possible to implicitly increase
alignment based on access patterns, or you'll break existing binaries.
This happened to affect libc++'s std::cout symbol, for example. See
thread: http://thread.gmane.org/gmane.comp.compilers.clang.devel/45311
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257719 91177308-0d34-0410-b5e6-96231b3b80d8
Previous implementation in http://reviews.llvm.org/D10522
created external references to __emutls_v.* variables.
Such references are inaccurate and cannot be handled by
all linkers, e.g. Android dynamic and gold linkers for aarch64.
Now a new LowerEmuTLS pass to go through all global variables,
and add emutls_v.* and emutls_t.* variables.
These __emutls* variables have the same linkage and
visibility as the associated user defined TLS variable.
Also removed old code that dump __emutls* variables in AsmPrinter.cpp,
and updated TLS unit tests.
Differential Revision: http://reviews.llvm.org/D15300
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257718 91177308-0d34-0410-b5e6-96231b3b80d8
Moves some .def files into include/DebugInfo/CodeView.
Aslo remove a 'using namespace' directive from a header in readobj and
update the uses of the endian helper types to compensate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257712 91177308-0d34-0410-b5e6-96231b3b80d8
[resubmit after fixing build bot failures: qualify make_unique and eliminate -Wcovered-switch-default warning.
With the planned size reduction change, the coverage format version is expected to be bumped up. This patch adds necessary support such that backward compatibility can be kept with maximal code sharing. Reading different versions of coverage data just requires instantiating the reader according to the version.
No functional change is intended.
Differiential Revision: http://reviews.llvm.org/D16133
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257708 91177308-0d34-0410-b5e6-96231b3b80d8