This actually totally breaks and causes the machine verifier to cry in several cases, one of which being:
%RAX<def> = COPY %RCX<kill>
%ECX<def> = COPY %EAX<kill>, %RAX<imp-use,kill>
These subregister copies are together identified as noops, so are both removed. However, the second one as it has an imp-use gets converted into a kill:
%ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill>
As the original COPY has been removed, the verifier goes into tears at the use of undefined EAX and RAX.
There are several hacky solutions to this hacky problem (which is all to do with imp-use/def weirdnesses), but the least hacky I've come up with is to *always* remove COPYs by converting to KILLs. KILLs are no-ops to the code generator so the generated code doesn't change (which is why they were partially used in the first place), but using them also keeps the def/use and imp-def/imp-use chains alive:
%RAX<def> = KILL %RCX<kill>
%ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill>
The patch passes all test cases including the ones that check the removal of MOVs in this circumstance, along with an extra test I added to check subregister behaviour (which made the machine verifier fall over before my patch).
The patch also adds some DEBUG() statements because the file hadn't got any.
llvm-svn: 199797
inconsistent results for different orderings of alloca slices. The
fundamental issue is that it is just always a mistake to return early
from this function. There is no effective early exit to leverage. This
patch stops trynig to do so and simplifies the code a bit as
a consequence.
Original diagnosis and patch by James Molloy with some name tweaks by me
in part reflecting feedback from Duncan Smith on the mailing list.
llvm-svn: 199771
The constructors of classes deriving from Binary normally take an error_code
as an argument to the constructor. My original intent was to change them
to have a trivial constructor and move the initial parsing logic to a static
method returning an ErrorOr. I changed my mind because:
* A constructor with an error_code out parameter is extremely convenient from
the implementation side. We can incrementally construct the object and give
up when we find an error.
* It is very efficient when constructing on the stack or when there is no
error. The only inefficient case is where heap allocating and an error is
found (we have to free the memory).
The result is that this is a much smaller patch. It just standardizes the
create* helpers to return an ErrorOr.
Almost no functionality change: The only difference is that this found that
we were trying to read past the end of COFF import library but ignoring the
error.
llvm-svn: 199770
Fix a crash in SjLjEHPrepare::lowerIncomingArguments caused by treating
VectorType like an aggregate. It's first-class!
<rdar://problem/15854596>
llvm-svn: 199768
For PPC64 SVR (and Darwin), the stores that take byval aggregate parameters
from registers into the stack frame had MachinePointerInfo objects with
incorrect offsets. These offsets are relative to the object itself, not to the
stack frame base.
This fixes self hosting on PPC64 when compiling with -enable-aa-sched-mi.
llvm-svn: 199763
This is apparently a bit of a white lie (they can affect DSPControl for
overflow etc) but similar to how we currently handle floating-point operations.
When it becomes relevant the whole lot can be reviewed properly.
llvm-svn: 199718
Add support to llvm-readobj to decode the actual opcodes. The ARM EHABI opcodes
are a variable length instruction set that describe the operations required for
properly unwinding stack frames.
The primary motivation for this change is to ease the creation of tests for the
ARM EHABI object emission as well as the unwinding directive handling in the ARM
IAS.
Thanks to Logan Chien for an extra test case!
llvm-svn: 199708
This implements the unwind_raw directive for the ARM IAS. The unwind_raw
directive takes the form of a stack offset value followed by one or more bytes
representing the opcodes to be emitted. The opcode emitted will interpreted as
if it were assembled by the opcode assembler via the standard unwinding
directives.
Thanks to Logan Chien for an extra test!
llvm-svn: 199707
The .personalityindex directive is equivalent to the .personality directive with
the ARM EABI personality with the specific index (0, 1, 2). Both of these
directives indicate personality routines, so enhance the personality directive
handling to take into account personalityindex.
Bonus fix: flush the UnwindContext at the beginning of a new function.
Thanks to Logan Chien for additional tests!
llvm-svn: 199706
It was commited as r199628 but reverted in r199628 as causing
regression test failed. It's because of old vervsion of patch
I used to commit. Sorry for mistake.
llvm-svn: 199704
to not guess at a symbol name in some cases.
The problem is that in object files assembled starting at address 0, when
trying to symbolicate something that starts like this:
% cat x.s
_t1:
vpshufd $0x0, %xmm1, %xmm0
the symbolic disassembly can end up like this:
% otool -tV x.o
x.o:
(__TEXT,__text) section
_t1:
0000000000000000 vpshufd $_t1, %xmm1, %xmm0
Which is in this case produced incorrect symbolication.
But it is useful in some cases to use the SymbolLookUp() call back
to guess at some immediate values. For example one like this
that does not have an external relocation entry:
% cat y.s
_t1:
movl $_d1, %eax
.data
_d1: .long 0
% clang -c -arch i386 y.s
% otool -tV y.o
y.o:
(__TEXT,__text) section
_t1:
0000000000000000 movl $_d1, %eax
% otool -rv y.o
y.o:
Relocation information (__TEXT,__text) 1 entries
address pcrel length extern type scattered symbolnum/value
00000001 False long False VANILLA False 2 (__DATA,__data)
So the change is based on it is not likely that an immediate Value
coming from an instruction field of a width of 1 byte, other than branches
and items with relocation, are not likely symbol addresses.
With the change the first case above simply becomes:
% otool -tV x.o
x.o:
(__TEXT,__text) section
_t1:
0000000000000000 vpshufd $0x0, %xmm1, %xmm0
and the second case continues to work as expected.
rdar://14863405
llvm-svn: 199698
when used with symbolic disassembly, add a check that the operand
is an immediate and has not been symbolicated to MCExpr operand.
I’m trying to enable the ‘C’ disassembly API option
LLVMDisassembler_Option_SetInstrComments for darwin’s
otool(1) that uses the llvm disassembler API. The problem is
that the disassembler API can change an immediate operand to
an MCExpr operand if it symbolicates it with the call backs.
And if it does the code in llvm::EmitAnyX86InstComments()
will crash when it assumes these operands are immediates.
The fix for this is very straight forward to just protect the call
to getImm() with a check of isImm(). So if the immediate for
an instruction is symbolicated it simply doesn’t get the X86
verbose assembly comments:
% otool -tV test_asm.o
test_asm.o:
(__TEXT,__text) section
_t1:
0000000000000000 vpshufd $_t1, %xmm1, %xmm0
0000000000000005 retq
0000000000000006 nopw %cs:_t1(%rax,%rax)
_t2:
0000000000000010 vpshufd $-0x1, %xmm0, %xmm0 ## xmm0 = xmm0[3,3,3,3]
0000000000000015 retq
0000000000000016 nopw %cs:_t1(%rax,%rax)
_t3:
0000000000000020 vpshufd $_t1, %xmm1, %xmm0
0000000000000025 retq
0000000000000026 nopw %cs:_t1(%rax,%rax)
_t4:
0000000000000030 vpshufd $0x2d, %xmm0, %xmm0 ## xmm0 = xmm0[1,3,2,0]
0000000000000035 retq
The fact that the immediate $0x0 is being symbolicated at
all in this case is a different problem which my next patch
will address.
rdar://10989286
llvm-svn: 199697
StackProtector keeps a ValueMap of alloca instructions to layout kind tags for
use by PEI and other later passes. When stack coloring replaces one alloca with
a bitcast to another one, the key replacement in this map does not work.
Instead, provide an interface to manage this updating directly. This seems like
an improvement over the old behavior, where the layout map would not get
updated at all when the stack slots were merged. In practice, however, there is
likely no observable difference because PEI only did anything special with
'large array' kinds, and if one large array is merged with another, than the
replacement should already have been a large array.
This is an attempt to unbreak the clang-x86_64-darwin11-RA builder.
llvm-svn: 199684
