x86_64 sibcall logic. I've filed PR9943 for the sibcall problem, and
this patch alters the testcase to work around the flaw. When PR9943
is fixed, this patch should be reverted.
llvm-svn: 131557
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
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
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
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
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
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
Roman Divacky