Starting on an input stream that is not at offset 0 would trigger the
assert in WinCOFFObjectWriter.cpp:1065:
assert(getStream().tell() <= (*i)->Header.PointerToRawData &&
"Section::PointerToRawData is insane!");
llvm-svn: 253464
The virtual register containing the address for returned value on
stack should in the DAG be represented with a CopyFromReg node and not
a Register node. Otherwise, InstrEmitter will not make sure that it
ends up in the right register class for the target instruction.
SystemZ needs this, becuause the reg class for address registers is a
subset of the general 64 bit register class.
test/SystemZ/CodeGen/args-07.ll and args-04.ll updated to run with
-verify-machineinstrs.
Reviewed by Hal Finkel.
llvm-svn: 253461
Symbolizers can call malloc/realloc/free/..., which we don't want to intercept. This is already implemented on Linux, let's do it for OS X as well.
Differential Revision: http://reviews.llvm.org/D14710
llvm-svn: 253460
Some expected attributes appear to be incorrect after
optimizations are run and llvm will strip them. Use -O0
so that llvm will not have a chance to remove them.
llvm-svn: 253458
Revert "Remove a few vestigial typedefs from the old world"
This reverts commit 05872cda2a00fbd988c4fc761b1f87fe9edce224.
Revert "Cleanup the type X list commands to use the new ForEach goodness"
This reverts commit 85b1d83819a22cdc9ef12f58fd4fa92b473a4f81.
llvm-svn: 253455
This time I've found a linux box and checked it there. This test now passes.
Because I'd introduced an undefined reference in @bar, gold now returns an error. This doesn't matter for the test itself, because it also emits the remarks the test is checking for. But it does cause LIT to notice a nonzero return code which it faults on.
llvm-svn: 253454
It needs the same fixes as in test/LTO/X86/remarks.ll, but this test appears not to get run on my system (but does on the buildbot). Strange.
llvm-svn: 253452
Added a new flag, --allow-static-binding. When specified,
if (and only if) the swig binary cannot be found, then the
LLDBWrapPython.cpp and lldb.py from the
scripts/Python/{static-binding-dir} are copied into the place where
swig would have generated them.
{static-binding-dir} defaults to static-binding, and can be
overridden with the --static-binding-dir command line argument.
The static bindings checked in are from r253424.
llvm-svn: 253448
Patch by Nitesh Jain
Summary: The self.getArchitecture() returns the architecture based on the value of -A flag passed to dotest.py script.
There are many possible values for MIPS to this option (like mips32r2, mips32r6, mips64, mips64r2,.... ).
This patch uses re.match(mips,arch) to check if architecture string starts with mips.
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Reviewers: clayborg, ovyalov
Differential: http://reviews.llvm.org/D14493
llvm-svn: 253444
We use to have an odd difference among MapVector and SetVector. The map
used a DenseMop, but the set used a SmallSet, which in turn uses a
std::set.
I have changed SetVector to use a DenseSet. If you were depending on the
old behaviour you can pass an explicit set type or use SmallSetVector.
The common cases for needing to do it are:
* Optimizing for small sets.
* Sets for types not supported by DenseSet.
llvm-svn: 253439
Summary:
This change teaches LLVM's inliner to track and suitably adjust
deoptimization state (tracked via deoptimization operand bundles) as it
inlines through call sites. The operation is described in more detail
in the LangRef changes.
Reviewers: reames, majnemer, chandlerc, dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14552
llvm-svn: 253438
If a section is rw, it is irrelevant if the dynamic linker will write to
it or not.
It looks like llvm implemented this because gcc was doing it. It looks
like gcc implemented this in the hope that it would put all the
relocated items close together and speed up the dynamic linker.
There are two problem with this:
* It doesn't work. Both bfd and gold will map .data.rel to .data and
concatenate the input sections in the order they are seen.
* If we want a feature like that, it can be implemented directly in the
linker since it knowns where the dynamic relocations are.
llvm-svn: 253436
Use `__builtin_offsetof` in place of `offsetof`. Certain environments provide a
macro definition of `offsetof` which may end up causing issues. This was
observed on Windows. Use `__builtin_offsetof` to ensure correct evaluation
everywhere. NFC.
llvm-svn: 253435
This patch emits a more appropriate (but still noisy) diagnostic stream when a lambda-expression is encountered within a non-type default argument.
For e.g. template<int N = ([] { return 5; }())> int f();
As opposed to complaining that a lambda expression is not allowed in an unevaluated operand, the patch complains about the lambda being forbidden in a constant expression context (which will be allowed in C++17 now that they have been accepted by EWG, unless of course CWG or national bodies (that have so far shown no signs of concern) rise in protest)
As I start submitting patches for constexpr lambdas (http://wg21.link/P0170R0) under C++1z (OK'd by Richard Smith at Kona), this will be one less change to make.
Thanks!
llvm-svn: 253431
Most linked executables do not have a symbol table in COFF.
However, it is pretty typical to have some export entries. Use those
entries to inform the disassembler about potential function definitions
and call targets.
llvm-svn: 253429
This commit is for a later patch that is depend on it. The sum of two
branch probabilities can be greater than 1 due to rounding. It is safer
to saturate the results of sum and subtraction.
llvm-svn: 253421
unsafe, since many operations on the types can trigger lazy deserialization of
more types and invalidate the iterators. This fixes a crasher, but I've not
been able to reduce it to a reasonable testcase yet.
llvm-svn: 253420
When looking for the best successor from the outer loop for a block
belonging to an inner loop, the edge probability computation can be
improved so that edges in the inner loop are ignored. For example,
suppose we are building chains for the non-loop part of the following
code, and looking for B1's best successor. Assume the true body is very
hot, then B3 should be the best candidate. However, because of the
existence of the back edge from B1 to B0, the probability from B1 to B3
can be very small, preventing B3 to be its successor. In this patch, when
computing the probability of the edge from B1 to B3, the weight on the
back edge B1->B0 is ignored, so that B1->B3 will have 100% probability.
if (...)
do {
B0;
... // some branches
B1;
} while(...);
else
B2;
B3;
Differential revision: http://reviews.llvm.org/D10825
llvm-svn: 253414
Manuel Klimek