Reapply r199191, reverted in r199197 because it carelessly broke
Other/link-opts.ll.  The problem was that calling
createInternalizePass("main") would select
createInternalizePass(bool("main")) instead of
createInternalizePass(ArrayRef<const char *>("main")).  This commit
fixes the bug.

The original commit message follows.

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: 199244

llvm-svn: 199243

llvm-svn: 199242

llvm-svn: 199241

llvm-svn: 199240

llvm-svn: 199239

symbols in case of executable file linking.

llvm-svn: 199238

_GLOBAL_OFFSET_TABLE_ symbol. We do not use this ponter anywhere after
assigning of virtual address.

llvm-svn: 199237

MipsTargetLayout class method.

llvm-svn: 199236

MIPS the entry symbol name is '__start' instead of '_start'.

llvm-svn: 199235

the lowest segment address to the MIPS_BASE_ADDRESS dynamic tag.

llvm-svn: 199234

method returns the DefaultLayout::_segments field. The type of this field is
a vector of Segment<ELFT>* pointers. This type cannot be implicitly casted to
the range<ChunkIter>.

llvm-svn: 199233

agains _gp_disp symbol.

llvm-svn: 199232

llvm-mc for an object file generation.

llvm-svn: 199231

llvm-svn: 199230

Simplifying the OpenCL image attribute. It does not need a semantic integer parameter because the required information is encoded in the spelling. Added an appropriate subject to the attribute, and simplified the semantic checking (which will likely be expanded upon in a future patch). Also, removed the GNU spelling since it was unsupported in the first place.

llvm-svn: 199229

llvm-svn: 199228

PR18472

llvm-svn: 199227

This allows the analyzer to handle properties with C++ class type,
finishing up the FIXME from r198953.

llvm-svn: 199226

Previously, the synthesized AST contained an rvalue DeclRefExpr for 'self'.
Now, it has an lvalue DeclRefExpr wrapped in an lvalue-to-rvalue
ImplicitCastExpr, which is what's generated when an ivar access is written
in the source.

No (intended) functionality change.

llvm-svn: 199225

llvm-svn: 199224

Newer unix systems have 32 bit uid and gid types, but the archive format was
not updated. Fortunately, these fields are not normally used. Just truncate
the data to fit in 6 chars.

llvm-svn: 199223

Update lib/buildit and test/testit to both pay attention to an env flag CXX_LANG, which people can set to 'c++03', 'c++11' or 'c++1y' to build/test using that language variant. If you don't set this env variable, you get c++11, just like today. Drive-by fix; remove duplicate -nostdinc++.

llvm-svn: 199222

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