Test case micromips-load-effective-address.s renamed to micromips-load-effective-address.ll and moved to test/CodeGen/Mips.

llvm-svn: 199221

With the old linkage types removed, set the linkage to external for both
dllimport and dllexport to reflect what's currently supported.

llvm-svn: 199220

llvm-svn: 199219

Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.

Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:

  define available_externally dllimport void @f() {}
  @Var = dllexport global i32 1, align 4

Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.

llvm-svn: 199218

removed AVX512SI format, since it is similar to AVX512BI.

llvm-svn: 199217

llvm-svn: 199216

The ClangCheck tool has changed and no longer is exactly equivalent to the
code pasted in the doc.

llvm-svn: 199215

Sorry, I don't understand why the warning is generated (a gcc
bug?). Anyhow, the change should improve readablity. No functionality
change intended.

llvm-svn: 199214

This fixes a regression intruced by r198113.

Revision r198113 introduced an algorithm that tries to fold a vector shift
by immediate count into a build_vector if the input vector is a known vector
of constants.

However the algorithm only worked under the assumption that the input vector
type and the shift type are exactly the same.

This patch disables the folding of vector shift by immediate count if the
input vector type and the shift value type are not the same.

llvm-svn: 199213

llvm-svn: 199212

It was incorrect anyway, since it didn't have accumulator inputs and wasn't
even supported on v5.

llvm-svn: 199211

Full language modes usually get listed before minor language extensions in
LangOpts, so that subsequent sub-modes can predicate on the major modes.

This also lends to a cleanup in CompilerInvocation to better indicate to the
reader that MSVCCompat is a superset of MicrosoftExt.

Cleanup only.

llvm-svn: 199210

There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.

MicrosoftExt (aka. fms-extensions):
 Enable largely unobjectionable Microsoft language extensions to ease
 portability. This mode, also supported by gcc, is used for building software
 like FreeBSD and Linux kernel extensions that share code with Windows drivers.

MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
 Turn on a special mode supporting 'heinous' extensions for drop-in
 compatibility with the Microsoft Visual C++ product. Standards-compilant C and
 C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.

Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.

See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'

No change in behaviour.

llvm-svn: 199209

llvm-svn: 199208

Revert this for now until I fix an issue in Clang with it.

This reverts commit r199204.

llvm-svn: 199207

This reverts commit r199205.

llvm-svn: 199206

llvm-svn: 199205

Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.

Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:

  define available_externally dllimport void @f() {}
  @Var = dllexport global i32 1, align 4

Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.

llvm-svn: 199204

fastcall requires @ as global prefix instead of _ but getNameWithPrefix
wrongly assumes the OutName buffer is empty and replaces at index 0.
For imported functions this buffer is pre-filled with "__imp_" resulting
in broken "@_imp_foo@0" mangling.

Instead replace at the proper index. We also never have to prepend the
@-prefix because this fastcall mangling is only used on 32-bit Windows
targets which have _ has global prefix.

llvm-svn: 199203

llvm-svn: 199202

llvm-svn: 199201

llvm-svn: 199200

llvm-svn: 199199

We cannot simply change the start column to accomodate for the @ in an
ObjC string literal as that will make clang-format happily violate the
column limit.

Use a different workaround instead. However, a better long-term
solution might be to join the @ and the rest of the literal into a
single token.

llvm-svn: 199198

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