Previously we needed to create atoms as a doubly-linked link, but it's
no longer needed. Also we don't use layout-after edges in PE/COFF.
Creating such edges is just waste.
llvm-svn: 230732
Nothing wrong with reinterpret_cast<llvm::support::ulittle32_t *>(loc),
but that's redundant and not great from readability point of view.
The new functions are wrappers for that kind of reinterpet_casts.
Surprisingly or unsurprisingly, there was no use of big endian read
and write. {read,write}{16,32,64}be have no user. But I think they
still worth to be there in the header for completeness.
http://reviews.llvm.org/D7927
llvm-svn: 230725
Currently, the ASan executables built with -O0 are unnecessarily slow.
The main reason is that ASan instrumentation pass inserts redundant
checks around promotable allocas. These allocas do not get instrumented
under -O1 because they get converted to virtual registered by mem2reg.
With this patch, ASan instrumentation pass will only instrument non
promotable allocas, giving us a speedup of 39% on a collection of
benchmarks with -O0. (There is no measurable speedup at -O1.)
llvm-svn: 230724
The ASanified executable could be launched from different locations. When we
cannot find the suppression file relative to the current directory, try to
see if the specified path is relative to the location of the executable.
llvm-svn: 230723
that is iterating over it
Inserting elements into a `DenseMap` invalidated iterators pointing
into the `DenseMap` instance.
Differential Revision: http://reviews.llvm.org/D7924
llvm-svn: 230719
AnalysisResult::getResultImpl reuses an iterator into a DenseMap after
inserting elements into it. This change adds code to recompute the
iterator before the second use.
llvm-svn: 230718
Summary:
This change causes us to actually save non-volatile registers in a Win64
ABI function that calls a System V ABI function, and vice-versa.
Reviewers: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7919
llvm-svn: 230714
uses of TM->getSubtargetImpl and propagate to all calls.
This could be a debugging regression in places where we had a
TargetMachine and/or MachineFunction but don't have it as part
of the MachineInstr. Fixing this would require passing a
MachineFunction/Function down through the print operator, but
none of the existing uses in tree seem to do this.
llvm-svn: 230710
Summary:
The code for GetSyntheticArrayMemberFromPointer and
GetSyntheticArrayMemberFromArray was identical, so just collapse the
the methods into one.
Reviewers: granata.enrico, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7911
llvm-svn: 230708
Function pointers were not correctly handled by the dumper, and
they would print as "* name". They now print as
"int (__cdecl *name)(int arg1, int arg2)" as they should.
Also, doubles were being printed as floats. This fixes that bug
as well, and adds tests for all builtin types. as well as a test
for function pointers.
llvm-svn: 230703
Previously we have a string -> string map to keep the weak alias
symbol mapping. Naturally we can't define more than one weak alias
with that data structure.
This patch is to allow multiple aliases for the same symbol by
changing the map type to string -> set of string map.
llvm-svn: 230702
a lookup, pass that in rather than use a naked call to getSubtargetImpl.
This involved passing down and around either a TargetMachine or
TargetRegisterInfo. Update all callers/definitions around the targets
and SelectionDAG.
llvm-svn: 230699
The __finally emission block tries to be clever by removing unused continuation
edges if there's an unconditional jump out of the __finally block. With
exception edges, the EH continuation edge isn't always unused though and we'd
crash in a few places.
Just don't be clever. That makes the IR for __finally blocks a bit longer in
some cases (hence small and behavior-preserving changes to existing tests), but
it makes no difference in general and it fixes the last crash from PR22553.
http://reviews.llvm.org/D7918
llvm-svn: 230697
blend as legal.
We made the same mistake in two different places. Whenever we are custom
lowering a v32i8 blend we need to check whether we are custom lowering
it only for constant conditions that can be shuffled, or whether we
actually have AVX2 and full dynamic blending support on bytes. Both are
fixed, with comments added to make it clear what is going on and a new
test case.
llvm-svn: 230695
Summary:
http://llvm.org/bugs/show_bug.cgi?id=20400
The default triple of i686-pc-linux-gnu for 32 bit linux targets is compatible
but not necessarily identical to the inferior binaries.
Applying Azat Khuzhin's solution of using ArchSpec::IsCompatibleMatch() instead
of ArchSpec::IsExactMatch() when comparing ObjectFile and Modules architecture.
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7897
llvm-svn: 230694
Summary:
There was no guarantee that the three threads haven't already exited by the
time the watchpoint is set.
Reviewers: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7916
llvm-svn: 230691
dynamic blends.
This makes it much more clear what is going on. The case we're handling
is that of dynamic conditions, and we're bailing when the nature of the
vector types and subtarget preclude lowering the dynamic condition
vselect as an actual blend.
No functionality changed here, but this will make a subsequent bug-fix
to this code much more clear.
llvm-svn: 230690
Rui Ueyama