llvm-svn: 131551

bool SectionLoadList::ResolveLoadAddress (addr_t load_addr, Address &so_addr) const;

Where if the address is in the last map entry, we need to look it up correctly.
My previous fix was incorrect where it looked in the first if there were
no addresses in the map that were > load_addr. Now we correctly look in the
last entry if our std::map::lower_bound search returns the end of the 
collection.

llvm-svn: 131550

Otherwise, pass m_arch.GetMachine().

Followup patch for rdar://problem/9170971.

llvm-svn: 131549

llvm-svn: 131548

llvm-svn: 131547

llvm-svn: 131546

llvm-svn: 131545

llvm-svn: 131544

llvm-svn: 131543

llvm-svn: 131542

llvm-svn: 131541

llvm-svn: 131540

llvm-svn: 131539

llvm-svn: 131538

Patch by Dan Bailey

llvm-svn: 131537

Original log entry:
Refactor getActionType and getTypeToTransformTo ; place all of the 'decision'
code in one place.

llvm-svn: 131536

code in one place.

llvm-svn: 131534

than either the primitive size or the element primitive size (in the case
of vectors), simplify the vector logic.  No functionality change.  There
is some distracting churn in the patch because I lined up comments better
while there - sorry about that.

llvm-svn: 131533

happily accept things like "sext <2 x i32> to <999 x i64>".  It would
also accept "sext <2 x i32> to i64", though the verifier would catch
that later.  Fixed by having castIsValid check that vector lengths match
except when doing a bitcast.  (2) When creating a cast instruction, check
that the cast is valid (this was already done when creating constexpr
casts).  While there, replace getScalarSizeInBits (used to allow more
vector casts) with getPrimitiveSizeInBits in getCastOpcode and isCastable
since vector to vector casts are now handled explicitly by passing to the
element types; i.e. this bit should result in no functional change.

llvm-svn: 131532

can be used to turn a <4 x i64> into a <4 x i32> but getCastOpcode would assert
if you passed these types to it.  Note that this strictly extends the previous
functionality: if getCastOpcode previously accepted two vector types (i.e. didn't
assert) then it still will and returns the same opcode (BitCast).  That's because
before it would only accept vectors with the same bitwidth, and the new code only
touches vectors with the same length.  However if two vectors have both the same
bitwidth and the same length then their element types have the same bitwidth, so
the new logic will return BitCast as before.

llvm-svn: 131530

In r131488 I misunderstood how VREV works. It splits the vector in half and splits each half. Therefore, the real problem was that we were using a VREV64 for a 4xi16, when we should have been using a VREV32.
Updated test case and reverted change to the PerfectShuffle Table.

llvm-svn: 131529

llvm-svn: 131528

llvm-svn: 131527

llvm-svn: 131526

GAS has no such directives (not even mingw-w64 GAS has them), so I took
creative license with their names in assembly. I prefixed them all with
"w64_" to avoid namespace collisions, for example. If I discover that GAS
has taken a different approach, I'll change ours to match.

llvm-svn: 131525

llvm-svn: 131524

The 'last use' may not be in the same basic block, and we still want a correct
live range.

llvm-svn: 131523

the purposes of the Win64 EH tables, I realized we had no way to tell where
the function ends. (MASM bounds functions with PROC and ENDP keywords.)
Add a directive to delimit the end of the function, and rename the 'frame'
directive to more accurately reflect its duality with the new directive.

llvm-svn: 131522

LiveInterval::shrinkToUses recomputes the live range from scratch instead of
removing snippets. This should avoid the problem with dangling live ranges.

Leave physreg identity copies alone. They can be created when joining a virtreg
with a physreg. They don't affect register allocation, and they will be removed
by the rewriter.

llvm-svn: 131521

member functions by making sure that they're on the record before
checking for deletion.

Also make sure source locations are valid to avoid crashes.

Unfortunately, the declare-all-implicit-members approach is still
required in order to ensure that dependency loops do not result in
incorrectly deleting functions (since they are to be deleted at the
declaration point per the standard).

Fixes PR9917

llvm-svn: 131520

llvm-svn: 131519

compare-and-swap intrinsics.

llvm-svn: 131518

bool
Address::SetLoadAddress (lldb::addr_t load_addr, Target *target);

Added an == and != operator to RegisterValue.

Modified the ThreadPlanTracer to use RegisterValue objects to store the
register values when single stepping. Also modified the output to be a bit
less wide.

Fixed the ABIMacOSX_arm to not overwrite stuff on the stack. Also made the
trivial function call be able to set the ARM/Thumbness of the target 
correctly, and also sets the return value ARM/Thumbness.

Fixed the encoding on the arm s0-s31 and d16 - d31 registers when the default
register set from a standard GDB server register sets.

llvm-svn: 131517

Start trying to make InstCombine preserve more debug info.  The idea here is to set the debug location on the IRBuilder, which will be then right location in most cases.  This should magically give many transformations debug locations, and fixing places which are missing a debug location will usually just means changing the code creating it to use the IRBuilder.

As an example, the change to InstCombineCalls catches a common case where a call to a bitcast of a function is rewritten.

Chris, does this approach look reasonable?

llvm-svn: 131516

I hear at least one person crying out in anguish, but it's unfortunately
necessary to avoid infinite loops with mutually dependent constructors
trying to call each other and determine if they are deleted.

It might be possible to go back to the old behavior if we can implement
part-of-file lookups efficiently, or if a solution is discovered by
which we can safely detect and avoid infinite recusion.

llvm-svn: 131515

llvm-svn: 131514

llvm-svn: 131512

llvm-svn: 131510

llvm-svn: 131509

llvm-svn: 131508