Please update also Other/link-opts.ll, in next time.

llvm-svn: 199197

This test provides definitions of size_t which are at odds with
-fms-compatibility.  Disable this test on those builders (for now).

llvm-svn: 199196

Builders that have -fms-compatibility on by default define size_t implicitly.
Tests that provide conflicting definitions would cause unintended failures.

llvm-svn: 199195

llvm-svn: 199194

Separate the concept of 16-bit/32-bit operand size controlled by 0x66 prefix and the current mode from the concept of SSE instructions using 0x66 prefix as part of their encoding without being affected by the mode.

This should allow SSE instructions to be encoded correctly in 16-bit mode which r198586 probably broke.

llvm-svn: 199193

struct stat defined in <asm/stat.h> is incorrect for x32.  <asm/stat.h>
is included to get struct __old_kernel_stat.  But struct __old_kernel_stat
isn't used for x86-64 nor x32.  This patch includes <sys/stat.h> instead
of <asm/stat.h> and comments out size check of struct __old_kernel_stat
for x86-64.

Patch by H.J. Lu

llvm-svn: 199192

Add API to LTOCodeGenerator to specify a strategy for the -internalize
pass.

This is a new attempt at Bill's change in r185882, which he reverted in
r188029 due to problems with the gold linker.  This puts the onus on the
linker to decide whether (and what) to internalize.

In particular, running internalize before outputting an object file may
change a 'weak' symbol into an internal one, even though that symbol
could be needed by an external object file --- e.g., with arclite.

This patch enables three strategies:

- LTO_INTERNALIZE_FULL: the default (and the old behaviour).
- LTO_INTERNALIZE_NONE: skip -internalize.
- LTO_INTERNALIZE_HIDDEN: only -internalize symbols with hidden
  visibility.

LTO_INTERNALIZE_FULL should be used when linking an executable.

Outputting an object file (e.g., via ld -r) is more complicated, and
depends on whether hidden symbols should be internalized.  E.g., for
ld -r, LTO_INTERNALIZE_NONE can be used when -keep_private_externs, and
LTO_INTERNALIZE_HIDDEN can be used otherwise.  However,
LTO_INTERNALIZE_FULL is inappropriate, since the output object file will
eventually need to link with others.

lto_codegen_set_internalize_strategy() sets the strategy for subsequent
calls to lto_codegen_write_merged_modules() and lto_codegen_compile*().

<rdar://problem/14334895>

llvm-svn: 199191

MSVC defines size_t without any explicit declarations.  This change
allows us to be compatible with TUs that depend on this declaration
appearing from nowhere.

llvm-svn: 199190

llvm-svn: 199189

Pad these structs up so they are sret-returned even on that
architecture.

llvm-svn: 199188

When creating a virtual register for a def, the value type should be
used to pick the register class. If we only use the register class
constraint on the instruction, we might pick a too large register class.

Some registers can store values of different sizes. For example, the x86
xmm registers can hold f32, f64, and 128-bit vectors. The three
different value sizes are represented by register classes with identical
register sets: FR32, FR64, and VR128. These register classes have
different spill slot sizes, so it is important to use the right one.

The register class constraint on an instruction doesn't necessarily care
about the size of the value its defining. The value type determines
that.

This fixes a problem where InstrEmitter was picking 32-bit register
classes for 64-bit values on SPARC.

llvm-svn: 199187

The already allocatable DPair superclass contains odd-even D register
pair in addition to the even-odd pairs in the QPR register class. There
is no reason to constrain the set of D register pairs that can be used
for NEON values. Any NEON instructions that require a Q register will
automatically constrain the register class to QPR.

The allocation order for DPair begins with the QPR registers, so
register allocation is unlikely to change much.

llvm-svn: 199186

llvm-svn: 199185

Rename libc++ internal templates __is_void, __is_integral, __is_floating_point, __is_pointer, __is_function_imp, __is_function, __is_member_function_pointer, __is_member_pointer, __is_signed_impl, __is_signed, __is_unsigned_impl, __is_unsigned to __libcpp_is_XXX, because some compilers have decided that __is_XXX are keywords. No functionality change.

llvm-svn: 199184

llvm-svn: 199183

requires Clang 3.1 or GCC 4.7. If the compiler isn't Clang or GCC, we
don't try to do any sanity checking, but this give us at least
a reasonable baseline of modern compilers.

Also, I'm not claiming that this is the best way to do compiler version
tests. I'm happy for anyone to suggest better ways of doing this test.

llvm-svn: 199182

This matches what gnu as does and implementing this is easier than arguing
about it.

llvm-svn: 199181

We need to ensure that StackSlotColoring.cpp does not reuse stack
spill slots in functions that call "returns_twice" functions such as
setjmp(), otherwise this can lead to miscompiled code, because a stack
slot would be clobbered when it's still live.

This was already handled correctly for functions that call setjmp()
(though this wasn't covered by a test), but not for functions that
invoke setjmp().

We fix this by changing callsFunctionThatReturnsTwice() to check for
invoke instructions.

This fixes PR18244.

llvm-svn: 199180

Also, so is stacker, llvm-tv, etc. Wow.

But will someone please fess up to what projects/privbracket is and why
our autoconf build supports it?

llvm-svn: 199179

llvm-svn: 199178

llvm-svn: 199177

llvm-svn: 199176

Removing some attribute magic related to the OpenCL keyword attributes. Instead of mapping them to their semantics as a custom part of the parser, they instead map declaratively through the rest of the attribute system.

llvm-svn: 199175

This will allow it to be called from target independent parts of the main
streamer that don't know if there is a registered target streamer or not. This
in turn will allow targets to perform extra actions at specified points in the
interface: add extra flags for some labels, extra work during finalization, etc.

llvm-svn: 199174

don't know their bit alignment.

llvm-svn: 199173

This patch makes a small behavioral change to the interaction between 
pack and alignment.  Specifically it makes __declspec(align()) on a 
field change that field's alignment without respect to pack but the 
alignment change to the record alignment as a whole still obeys pack.

llvm-svn: 199172

Record layout will tell us the offset of a shared vbptr inside a
non-virtual base.

No functionality change.

llvm-svn: 199171

llvm-svn: 199170

consumable objects.  These are useful for implementing error codes that
must be checked.  Patch also includes some significant refactoring, which was
necesary to implement the new behavior.

llvm-svn: 199169

Although VBPtrs were being placed correctly by the ms-abi layout engine, 
their offsets were being improperly reported to the ASTRecordLayout 
builder due to a bug.  This patch fixes that and fixes the test cases to 
use the correct values.
y

llvm-svn: 199168

llvm-svn: 199167

llvm-svn: 199166

llvm-svn: 199165

llvm-svn: 199164

llvm-svn: 199163

llvm-svn: 199162

llvm-svn: 199161

Fixes PR18435, where we generated a base ctor instead of a complete
ctor, and so failed to construct virtual bases when constructing the
complete object.

llvm-svn: 199160

llvm-svn: 199159

llvm-svn: 199158