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

llvm-svn: 199705

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

llvm-svn: 199703

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

llvm-svn: 199702

we can see exactly what data was put where.

llvm-svn: 199701

I misunderstood the discussion on this. The complexity here is
justified by the malloc overhead it saves.

This reverts commit r199302.

llvm-svn: 199700

llvm-svn: 199699

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

Recent versions of the iOS simulator no longer require linking with the
crt1.o, dylib1.o, or bundle1.o files. The relevant code is now included in
libSystem for the simulator.

llvm-svn: 199696

llvm-svn: 199695

Fixed test failure in is_iec559.pass.cpp on darwin-ppc32. Thanks to David Fang for the report (and suggested fix)

llvm-svn: 199694

llvm-svn: 199689

Without them they can be merged with non unnamed_addr constants during LTO.
The resulting constant is not unnamed_addr and goes in a different section,
which causes ld64 to crash.

A testcase that would crash before:

* file1.mm:
void g(id notification) {
  [notification valueForKey:@"name"];
}

* file2.cpp:
extern const char js_name_str[] = "name";

* file3.cpp
extern bool JS_GetProperty(const char *name);
extern const char js_name_str[];
bool js_ReportUncaughtException() { JS_GetProperty(js_name_str); }

run

clang file1.mm  -o file1.o -c -w -emit-llvm
clang file2.cpp -o file2.o -c -w -emit-llvm
clang file3.cpp -o file3.o -c -w

ld -dylib -o XUL file1.o file2.o file3.o -undefined dynamic_lookup.

llvm-svn: 199688

Patch by: Udo van den Heuvel

Tom Stellard:
  - Added ifdef and error handling

llvm-svn: 199687

Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.

Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.

Will keep an eye on the builders and update dependent projects shortly.

No functional change.

llvm-svn: 199686

Thanks to David Blaikie for the push.

llvm-svn: 199685

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

Add target specific rules for combining vselect dag nodes into movss/movsd
when possible.

If the vector type of the vselect dag node in input is either MVT::v4i13 or
MVT::v4f32, then try to fold according to rules:

  1) fold (vselect (build_vector (0, -1, -1, -1)), A, B) -> (movss A, B)
  2) fold (vselect (build_vector (-1, 0, 0, 0)), A, B) -> (movss B, A)

If the vector type of the vselect dag node in input is either MVT::v2i64 or
MVT::v2f64 (and we have SSE2), then try to fold according to rules:

  3) fold (vselect (build_vector (0, -1)), A, B) -> (movsd A, B)
  4) fold (vselect (build_vector (-1, 0)), A, B) -> (movsd B, A)

llvm-svn: 199683

when the deployment target is 10.5. // rdar://15852259

llvm-svn: 199682

optional DWARF sections, so compiling with -g does not result in
different code being generated for PC-relative loads.

This is reapplying a diet r197922 (__TEXT-only).

llvm-svn: 199681

Cut back on the cargo cult. The order of __DATA sections doesn't affect
generated code.

This reverts commit r197922.

llvm-svn: 199680

Adding a bit of documentation that was missed with r198883 (when ParseArgumentsAsUnevaluated was added).

llvm-svn: 199679

Allow SMUL_LOHI and UMUL_LOHI to be narrow to MUL on targets where MUL is Custom rather than Legal.  Even if the target is doing some kind of expansion for MUL, it's pretty much guaranteed to be more efficent than whatever it does for SMUL_LOHI or UMUL_LOHI!

llvm-svn: 199678

Exposed a declarative way to specify that an attribute can be duplicated when merging attributes on a declaration. This replaces some hard-coded functionality from Sema.

llvm-svn: 199677

Remove some hard-coded specialness for thread-safety attributes from the parser, and made it more declarative. If an attribute is allowed to appear on a function definition when late parsed, it can now use the FunctionDefinition attribute subject. It's treated as a FunctionDecl for most purposes, except it also gets exposed on the AttributeList so that it can be used while parsing.

llvm-svn: 199676

Remove the useless pseudo instructions VDUPfdf and VDUPfqf, replacing them with patterns to match VDUPLN.

llvm-svn: 199675

I didn't realize that cmake_parse_arguments() would require explicit inclusion.

llvm-svn: 199674

Before:
  option(my_option) = "abc";

After:
  option (my_option) = "abc";

llvm-svn: 199672

llvm-svn: 199671

llvm-svn: 199670

llvm-svn: 199669

llvm-svn: 199667

Fixing a typo (turned out to be harmless since the default priority values are the same between the two attributes).

llvm-svn: 199666

llvm-svn: 199665

Since the diagnostics engine understands Attr objects, this code is no longer required -- we can just pass in the attribute directly.

llvm-svn: 199664

llvm-svn: 199663

HasFunctionProto is a more strict version of FunctionLike. Since attribute subjects are inclusive (passing a single subject test means no subject-related diagnostic will fire), these two subjects should not be combined.

llvm-svn: 199662