Fixes PR15838. Need to check for blocks with nothing but dbg.value.
I'm not sure how to force this situation with a unit test. I tried to
reduce the test case in PR15838 (1k lines of metadata) but gave up.
llvm-svn: 180227
There is a new static ObjectFile function you can call:
size_t
ObjectFile::GetModuleSpecifications (const FileSpec &file,
lldb::offset_t file_offset,
ModuleSpecList &specs)
This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question).
This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info.
llvm-svn: 180224
Due to the semantics of ARC, we must be extremely conservative with autorelease
calls inserted by the frontend since ARC gaurantees that said object will be in
the autorelease pool after that point, an optimization invariant that the
optimizer must respect.
On the other hand, we are allowed significantly more flexibility with
autoreleaseRV instructions.
Often times though this flexibility is disrupted by early transformations which
transform objc_autoreleaseRV => objc_autorelease if said instruction is no
longer being used as part of an RV pair (generally due to inlining). Since we
can not tell the difference in between an autorelease put into place by the
frontend and one created through said ``strength reduction'' we can not perform
these optimizations.
The addition of this set gets around said issues by allowing us to differentiate
in between said two cases.
rdar://problem/13697741.
llvm-svn: 180222
The user was trying to obtain the address-of an std::vector and the experience was more painful than necessary because data formatters were kicking in for vector* objects
We got this right for libc++ - we should get it right for libstdc++ too
llvm-svn: 180219
(normally undefined) as indicating a breakpoint hit, in addition
to the normal (EXC_BREAKPOINT, EXC_ARM_BREAKPOINT) pair.
<rdar://problem/13730366>
llvm-svn: 180216
While here, don't report a dummy symbol for relocations that don't have symbols.
We used to says such relocations were for the first defined symbol, but now we
return end_symbols(). The llvm-readobj output change agrees with otool.
llvm-svn: 180214
out of the runtime. This allows calling static methods
on classes whose symbols have been stripped out of the
binary.
<rdar://problem/12042992>
llvm-svn: 180210
Specifically, allow the flags that fall under this umbrella (i.e., -O3,
-ffast-math, and -fstrict-aliasing) to be overridden/disabled with the
individual -O[0|1|2|s|z]/-fno- flags.
This also fixes the handling of various floating point optimization
flags that are modified by -ffast-math (and thus -Ofast as well).
Part of rdar://13622687
llvm-svn: 180204
LTO was always creating an empty llvm.compiler.used. With this patch we
now first check if there is anything to be added first.
Unfortunately, there is no good way to test libLTO in isolation as it needs gold
or ld64, but there are bots doing LTO builds that found this problem.
llvm-svn: 180202
That seems to interact poorly with the environ and _environ macros
defined in MSVC's <stdlib.h>.
Also remove the incorrect comment about _NSGetEnviron().
llvm-svn: 180200
categories, do not report when they are declared in primary class,
class's protocol, or one of it super classes. This is because,
its class is going to implement them. // rdar://13713098
llvm-svn: 180198
This patch disables memory-instruction vectorization for types that need padding
bytes, e.g., x86_fp80 has 10 bytes store size with 6 bytes padding in darwin on
x86_64. Because the load/store vectorization is performed by the bit casting to
a packed vector, which has incompatible memory layout due to the lack of padding
bytes, the present vectorizer produces inconsistent result for memory
instructions of those types.
This patch checks an equality of the AllocSize of a scalar type and allocated
size for each vector element, to ensure that there is no padding bytes and the
array can be read/written using vector operations.
Patch by Daisuke Takahashi!
Fixes PR15758.
llvm-svn: 180196
For now, we just reschedule instructions that use the copied vregs and
let regalloc elliminate it. I would really like to eliminate the
copies on-the-fly during scheduling, but we need a complete
implementation of repairIntervalsInRange() first.
The general strategy is for the register coalescer to eliminate as
many global copies as possible and shrink live ranges to be
extended-basic-block local. The coalescer should not have to worry
about resolving local copies (e.g. it shouldn't attemp to reorder
instructions). The scheduler is a much better place to deal with local
interference. The coalescer side of this equation needs work.
llvm-svn: 180193
When MachineScheduler is enabled, this functionality can be
removed. Until then, provide a way to disable it for test cases and
designing MachineScheduler heuristics.
llvm-svn: 180192
Since the relocation iterator walks only the relocations in one section, we
can just use a pointer and avoid fetching information about the section at
every reference.
llvm-svn: 180189
Summary:
Added support for multiple input files, that can be used both with and
without in-place edit (-i) option. Added checks for -offset and -length options:
don't allow them on multiple files, check that they don't fall outside input
file, made both options unsigned, so that there's no need to check for negative
values. Removed "-1 can be used for end-of-file" from -length description.
Reviewers: djasper, klimek
Reviewed By: djasper
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D719
llvm-svn: 180185
Andrew Kaylor