Fixes PR#18521

llvm-svn: 199775

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

match the (reasonably prevelant) usage in Clang's test suite and so
seems more "canonical".

llvm-svn: 199767

Generalized the heuristic that looks at the (very rough) size of the
register file before enabling regpressure tracking.

llvm-svn: 199766

llvm-svn: 199765

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

dependent libraries from a bitcode module.

Differential Revision: http://llvm-reviews.chandlerc.com/D2343

llvm-svn: 199759

C compilations as well and these flags don't make any sense there.

llvm-svn: 199756

llvm-svn: 199753

llvm-svn: 199751

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199749

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199748

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199747

llvm-svn: 199746

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199743

llvm-svn: 199742

No functional change

llvm-svn: 199741

No functional change

llvm-svn: 199738

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199737

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199734

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199732

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199728

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199727

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199722

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199719

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

llvm-svn: 199716

llvm-svn: 199714

llvm-svn: 199712

Try to repair the ARM Cortex-A15 buildbot by using a more appropriate conversion
specifier.

llvm-svn: 199711

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

the header forwards to operator== which is not in the header.

llvm-svn: 199702

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