Allow handling of vectors during return lowering at least for little endian machines.
This was restricted in r208200 to fix it for big endian machines (according to
the comment), but it also disabled it for little endian too.
llvm-svn: 217846
The problem was the read_func we were supplying to the interactive interpreter wasn't stripping the newline from the end of the string. Now it does and multi-line python scripts can be typed in Xcode.
<rdar://problem/17696438>
llvm-svn: 217843
This allows us to fixup the address of the symbol as soon as we parse it
so that lldb is not confused thinking there are two different symbols in
the binary (one with the thumb bit, one without). Also, differentiating
between THUMB and ARM symbols allows the debugger to place the right
type of breakpoint.
Change by Stephane Sezer.
llvm-svn: 217841
This changes the debug output of the llvm-cov tool to consistently
write to stderr, and moves the highlighting output closer to where
it's relevant.
llvm-svn: 217838
In r217746, though it was supposed to be NFC, I broke llvm-cov's
handling of showing regions without showing counts. This should've
shown up in the existing tests, except they were checking debug output
that was displayed regardless of what was actually output. I've moved
the relevant debug output to a more appropriate place so that the
tests catch this kind of thing.
llvm-svn: 217835
This lowers frem to a runtime libcall inside fast-isel.
The test case also checks the CallLoweringInfo bug that was exposed by this
change.
This fixes rdar://problem/18342783.
llvm-svn: 217833
This fixes a bug in FastISel::CallLoweringInfo, where the number of
arguments was obtained from the argument vector before it had been
initialized.
Test case follows in another commit.
llvm-svn: 217832
We already have routines to encode SLEB128 as well as encode/decode ULEB128.
This last function fills out the matrix. I'll need this for some llvm-objdump
work I am doing.
llvm-svn: 217830
a property assignment due to numerous user errors.
Cannot come up with a reasonable test case due to
array of user errors before the crash point.
rdar://17813651.
llvm-svn: 217825
Summary: UsedByBranch is always true according to how BonusInst is defined.
Test Plan:
Passes check-all, and also verified
if (BonusInst && !UsedByBranch) {
...
}
is never entered during check-all.
Reviewers: resistor, nadav, jingyue
Reviewed By: jingyue
Subscribers: llvm-commits, eliben, meheff
Differential Revision: http://reviews.llvm.org/D5324
llvm-svn: 217824
Summary:
Expand list of supported targets for Mips to include mips32 r1.
Previously it only include r2. More patches are coming where there is
a difference but in the current patches as pushed upstream, r1 and r2
are equivalent.
Test Plan:
simplestorefp1.ll
add new build bots at mips to test this flavor at both -O0 and -O2
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D5306
llvm-svn: 217821
introducing a synthetic X86 ISD node representing this generic
operation.
The relevant patterns for mapping these nodes into the concrete
instructions are also added, and a gnarly bit of C++ code in the
target-specific DAG combiner is replaced with simple code emitting this
primitive.
The next step is to generically combine blends of adds and subs into
this node so that we can drop the reliance on an SSE4.1 ISD node
(BLENDI) when matching an SSE3 feature (ADDSUB).
llvm-svn: 217819
There are several places where multiple threads are accessing the same variables simultaneously without any kind of protection. I propose using std::atomic<> to make it safer. I did a special build of lldb, using the google tool 'thread sanitizer' which identified many cases of multiple threads accessing the same memory. std::atomic is low overhead and does not use any locks for simple types such as int/bool.
See http://reviews.llvm.org/D5302 for more details.
Change by Shawn Best.
llvm-svn: 217818
Change 1: we used to add static sanitizer runtimes at the
very beginning of the linker invocation, even before crtbegin.o, which
is gross and not correct in general. Fix this: now addSanitizerRuntimes()
adds all sanitizer-related link flags to the end of the linker invocation
being constructed. It means, that we should call this function in the
correct place, namely, before AddLinkerInputs() to make sure sanitizer
versions of library functions will be preferred.
Change 2: Put system libraries sanitizer libraries depend on at the
end of the linker invocation, where all the rest system libraries are
located. Respect --nodefaultlibs and --nostdlib flags. This is another way
to fix PR15823. Original fix landed in r215940 put "-lpthread" and friends
immediately after static ASan runtime, before the user linker inputs.
This caused significant slowdown in dynamic linker for large binaries
linked against thousands of shared objects. Instead, to mark system
libraries as DT_NEEDED we prepend them with "--no-as-needed" flag,
discarding the "-Wl,--as-needed" flag that could be provided by the user.
Otherwise, this change is a code cleanup. Instead of having a special method
for each sanitizer, we introduce a function collectSanitizerRuntimes() that
analyzes -fsanitize= flags and returns the set of static and shared
libraries that needs to be linked.
llvm-svn: 217817
There are target pointer members in struct jit_code_entry and jit_descriptor.
Data layout of those structures should be decided by target, not host.
This fixes JITLoaderGDB for 64-bit host and 32-bit target.
See http://reviews.llvm.org/D5339 for more details.
Change by Tong Shen.
llvm-svn: 217816
Teach WinCOFFObjectWriter how to write -mbig-obj style object files;
these object files allow for more sections inside an object file.
Our support for BigObj is notably different from binutils and cl: we
implicitly upgrade object files to BigObj instead of asking the user to
compile the same file *again* but with another flag. This matches up
with how LLVM treats ELF variants.
This was tested by forcing LLVM to always emit BigObj files and running
the entire test suite. A specific test has also been added.
I've lowered the maximum number of sections in a normal COFF file,
VS "14" CTP 3 supports no more than 65279 sections. This is important
otherwise we might not switch to BigObj quickly enough, leaving us with
a COFF file that we couldn't link.
yaml2obj support is all that remains to implement.
Differential Revision: http://reviews.llvm.org/D5349
llvm-svn: 217812
There's some other cleanup that could happen here, but this is at least
the mechanical transformation to unique_ptr.
Derived from a patch by Anton Yartsev.
llvm-svn: 217803
We use SplitEdge to split a conditional entry edge of the SCoP region.
However, SplitEdge can cause two different situations (depending on
whether or not the edge is critical). This patch tests
which one is present and deals with the former unhandled one.
It also refactors and unifies the case we have to change the basic
blocks of the SCoP to new ones (see replaceScopAndRegionEntry).
llvm-svn: 217802
On MachO, and MachO only, we cannot have a truly empty function since that
breaks the linker logic for atomizing the section.
When we are emitting a frame pointer, the presence of an unreachable will
create a cfi instruction pointing past the last instruction. This is perfectly
fine. The FDE information encodes the pc range it applies to. If some tool
cannot handle this, we should explicitly say which bug we are working around
and only work around it when it is actually relevant (not for ELF for example).
Given the unreachable we could omit the .cfi_def_cfa_register, but then
again, we could also omit the entire function prologue if we wanted to.
llvm-svn: 217801
introduced in r217629.
We were returning the old sext instead of the new zext as the promoted instruction!
Thanks Joerg Sonnenberger for the test case.
llvm-svn: 217800
Peephole optimization was folding MOVSDrm, which is a zero-extending double
precision floating point load, into ADDPDrr, which is a SIMD add of two packed
double precision floating point values.
(before)
%vreg21<def> = MOVSDrm <fi#0>, 1, %noreg, 0, %noreg; mem:LD8[%7](align=16)(tbaa=<badref>) VR128:%vreg21
%vreg23<def,tied1> = ADDPDrr %vreg20<tied0>, %vreg21; VR128:%vreg23,%vreg20,%vreg21
(after)
%vreg23<def,tied1> = ADDPDrm %vreg20<tied0>, <fi#0>, 1, %noreg, 0, %noreg; mem:LD8[%7](align=16)(tbaa=<badref>) VR128:%vreg23,%vreg20
X86InstrInfo::foldMemoryOperandImpl already had the logic that prevented this
from happening. However the check wasn't being conducted for loads from stack
objects. This commit factors out the logic into a new function and uses it for
checking loads from stack slots are not zero-extending loads.
rdar://problem/18236850
llvm-svn: 217799
Juergen Ributzka