On Darwin it is currently impossible to build LLVM with modules
because the Darwin system module map is not compatible with
-fmodules-local-submodule-visibility at this point in time.  This
patch makes the flag optional and off by default on Darwin so it
becomes possible to build LLVM with modules again.

http://reviews.llvm.org/D21827
rdar://problem/27019000

llvm-svn: 274196

llvm-svn: 274195

- Use range based for loops
- No need for some !Reg checks: isPhysicalRegister() reports false for
  NoRegister anyway
- Do not repeat function name in documentation comment.
- Do not repeat documentation comment in implementation when we already
  have one at the declaration.
- Factor some common subexpressions out.
- Change file comments to use doxygen syntax.

llvm-svn: 274194

Add an explicit overload to BuildMI for MachineInstr& to deal with
insertions inside of instruction bundles.

- Use it to re-implement MachineInstr* to give it coverage.

- Document how the overload for MachineBasicBlock::instr_iterator
  differs from that for MachineBasicBlock::iterator (the previous
  (implicit) overload for MachineInstr&).

- Add a comment explaining why the MachineInstr& and MachineInstr*
  overloads don't universally forward to the
  MachineBasicBlock::instr_iterator overload.

Thanks to Justin for noticing the API quirk.  While this doesn't fix any
known bugs -- all uses of BuildMI with a MachineInstr& were previously
using MachineBasicBlock::iterator -- it protects against future bugs.

llvm-svn: 274193

llvm-svn: 274192

This function is already a bit too long, and I'm about to make it worse.

llvm-svn: 274191

MSVC doesn't pack the bit field members if different types are used.
This came up in a patch review.

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160627/163107.html

llvm-svn: 274190

This is mostly a mechanical change to make TargetInstrInfo API take
MachineInstr& (instead of MachineInstr* or MachineBasicBlock::iterator)
when the argument is expected to be a valid MachineInstr.  This is a
general API improvement.

Although it would be possible to do this one function at a time, that
would demand a quadratic amount of churn since many of these functions
call each other.  Instead I've done everything as a block and just
updated what was necessary.

This is mostly mechanical fixes: adding and removing `*` and `&`
operators.  The only non-mechanical change is to split
ARMBaseInstrInfo::getOperandLatencyImpl out from
ARMBaseInstrInfo::getOperandLatency.  Previously, the latter took a
`MachineInstr*` which it updated to the instruction bundle leader; now,
the latter calls the former either with the same `MachineInstr&` or the
bundle leader.

As a side effect, this removes a bunch of MachineInstr* to
MachineBasicBlock::iterator implicit conversions, a necessary step
toward fixing PR26753.

Note: I updated WebAssembly, Lanai, and AVR (despite being
off-by-default) since it turned out to be easy.  I couldn't run tests
for AVR since llc doesn't link with it turned on.

llvm-svn: 274189

llvm-svn: 274188

- Use range based for
- Use the more common variable names MBB and MF for
  MachineBasicBlock/MachineFunction variables.
- Add a few const modifiers

llvm-svn: 274187

llvm-svn: 274186

Reviewers: rsmith, saugustine, rnk

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D21666

llvm-svn: 274185

Differential Revision: http://reviews.llvm.org/D21722

llvm-svn: 274184

The NewArchiveIterator class has a problem: it requires too much context. Any
memory buffers added to the archive must be stored within an Archive::Member,
which must have an associated Archive. This makes it harder than necessary
to create new archive members (or new archives entirely) from scratch using
memory buffers.

This patch replaces NewArchiveIterator with a NewArchiveMember class that
stores just the memory buffer and the information that goes into the archive
member header.

Differential Revision: http://reviews.llvm.org/D21721

llvm-svn: 274183

llvm-svn: 274182

llvm-svn: 274180

[ClangConfig] Unset some variables after we are done using them to configure ClangConfig.cmake.in files.

This ensures that the values do not bleed over in between computations. It may
make sense in the future to just refactor this code into functions to provide
"true scoping".

llvm-svn: 274179

[ClangConfig] Instead of hard coding the ClangTargets location to /ClangTargets.cmake, follow LLVM's example and use a pre-computed cmake variable @CLANG_CONFIG_EXPORTS_FILE@.

This just makes ClangConfig more consistent with LLVMConfig.

llvm-svn: 274178

[ClangConfig] Follow LLVM's example and only install Clang{Config,Target}.cmake when LLVM_INSTALL_TOOLCHAIN_ONLY is disabled.

llvm-svn: 274177

This will allow for cmake to expand variables in ClangConfig.cmake for
downstream users.

llvm-svn: 274176

This matches more closely the rest of the variables in LLVMConfig.cmake which
shed the _CONFIG_ part of their names.

llvm-svn: 274175

Summary:
This patch is fixing unittests that are broken on windows (64-bits).

Tests under 'SANITIZER_CAN_USE_ALLOCATOR64' are disabled.
A custom allocator for windows based on WinHeap API will replace these tests.

Tested on Win32/Win64 (Ninja and MSVC).
Tested on Linux 32-bit/64-bit clang.

```
C:\src\llvm\build64\projects\compiler-rt>lib\sanitizer_common\tests\Release\Sanitizer-x86_64-Test.exe
[==========] Running 101 tests from 12 test cases.
[----------] Global test environment set-up.
[----------] 51 tests from SanitizerCommon
[ RUN      ] SanitizerCommon.DefaultSizeClassMap
[       OK ] SanitizerCommon.DefaultSizeClassMap (1 ms)
[ RUN      ] SanitizerCommon.CompactSizeClassMap
[       OK ] SanitizerCommon.CompactSizeClassMap (1 ms)
[ RUN      ] SanitizerCommon.InternalSizeClassMap
[       OK ] SanitizerCommon.InternalSizeClassMap (1 ms)
[ RUN      ] SanitizerCommon.SizeClassAllocator32Compact
[       OK ] SanitizerCommon.SizeClassAllocator32Compact (828 ms)
[ RUN      ] SanitizerCommon.SizeClassAllocator32CompactMetadataStress
[       OK ] SanitizerCommon.SizeClassAllocator32CompactMetadataStress (914 ms)
[ RUN      ] SanitizerCommon.SizeClassAllocator32MapUnmapCallback

[...]

[----------] 4 tests from Symbolizer
[ RUN      ] Symbolizer.ExtractToken
[       OK ] Symbolizer.ExtractToken (0 ms)
[ RUN      ] Symbolizer.ExtractInt
[       OK ] Symbolizer.ExtractInt (0 ms)
[ RUN      ] Symbolizer.ExtractUptr
[       OK ] Symbolizer.ExtractUptr (0 ms)
[ RUN      ] Symbolizer.ExtractTokenUpToDelimiter
[       OK ] Symbolizer.ExtractTokenUpToDelimiter (0 ms)
[----------] 4 tests from Symbolizer (24 ms total)

[----------] Global test environment tear-down
[==========] 101 tests from 12 test cases ran. (5090 ms total)
[  PASSED  ] 101 tests.
```

Reviewers: rnk

Subscribers: chrisha, wang0109, llvm-commits, kubabrecka

Differential Revision: http://reviews.llvm.org/D21817

llvm-svn: 274174

This makes it possible to e.g copy a report to another filesystem.

llvm-svn: 274173

Summary:
The build bot is broken because the runtime library doesn't have
debug information.

This is broken due to a recent change:
  http://reviews.llvm.org/D21554

Reviewers: rnk

Subscribers: kubabrecka, llvm-commits, chrisha

Differential Revision: http://reviews.llvm.org/D21862

llvm-svn: 274172

This fixes an issue where occurrence counts would be unexpectedly
reset when parsing different parts of a command line multiple
times.

**ORIGINAL COMMIT MESSAGE**

This allows command line tools to use syntaxes like the following:

      llvm-foo.exe command1 -o1 -o2
      llvm-foo.exe command2 -p1 -p2

Where command1 and command2 contain completely different sets of
valid options.  This is backwards compatible with previous uses
of llvm cl which did not support subcommands, as any option
which specifies no optional subcommand (e.g. all existing
code) goes into a special "top level" subcommand that expects
dashed options to appear immediately after the program name.
For example, code which is subcommand unaware would generate
a command line such as the following, where no subcommand
is specified:

      llvm-foo.exe -q1 -q2

The top level subcommand can co-exist with actual subcommands,
as it is implemented as an actual subcommand which is searched
if no explicit subcommand is specified.  So llvm-foo.exe as
specified above could be written so as to support all three
aforementioned command lines simultaneously.

There is one additional "special" subcommand called AllSubCommands,
which can be used to inject an option into every subcommand.
This is useful to support things like help, so that commands
such as:

      llvm-foo.exe --help
      llvm-foo.exe command1 --help
      llvm-foo.exe command2 --help

All work and display the help for the selected subcommand
without having to explicitly go and write code to handle each
one separately.

This patch is submitted without an example of anything actually
using subcommands, but a followup patch will convert the
llvm-pdbdump tool to use subcommands.

Reviewed By: beanz

llvm-svn: 274171

No semantic analysis yet.

This is a pain to disambiguate correctly, because the parsing rules for the
declaration form of a condition and of an init-statement are quite different --
for a token sequence that looks like a declaration, we frequently need to
disambiguate all the way to the ')' or ';'.

We could do better here in some cases by stopping disambiguation once we've
decided whether we've got an expression or not (rather than keeping going until
we know whether it's an init-statement declaration or a condition declaration),
by unifying our parsing code for the two types of declaration and moving the
syntactic checks into Sema; if this has a measurable impact on parsing
performance, I'll look into that.

llvm-svn: 274169

[ClangConfig] Copy ClangConfig.cmake to ${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR} instead of to ${CLANG_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}.

This is an obvious bug since ClangConfig.cmake looks for ClangTargets.cmake in
${CMAKE_CURRENT_LIST_DIR}. But ClangTargets.cmake is in
${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}, so it will always fail with an
in tree build.

In the case where clang is built out of tree, this is still correct since
CMAKE_BINARY_DIR and CLANG_BINARY_DIR will be the same.

llvm-svn: 274168

llvm-svn: 274167

llvm-svn: 274165

Fixes rdar://27002512

llvm-svn: 274164

The change causes llvm crash in some unoptimized builds.

llvm-svn: 274163

This is a fix for PR27842.

An IR-level implementation of stack coloring tailored to work with
SafeStack. It is a bit weaker than the MI implementation in that it
does not the "lifetime start at first access" logic. This can be
improved in the future.

This patch also replaces the naive implementation of stack frame
layout with a greedy algorithm that can split existing stack slots
and even fit small objects inside the alignment padding of other
objects.

llvm-svn: 274162

Matching change for lld for the llvm change of Archive::create() from ErrorOr<...> to Expected<...> in r274160.

llvm-svn: 274161

its clients.

This commit will break the next lld builds.  I’ll be committing the matching
change for lld next.

llvm-svn: 274160

Validate the option index before trying to access an array element using it - OptionArgElement can potentially use negative indices to mean interesting, but non option, states

llvm-svn: 274159

[ClangConfig] Replace paths with the same value as CLANG_INSTALL_PACKAGE_DIR with a deref of the variable.

llvm-svn: 274158

[cmake] Move creation of ClangTargets and installation of ClangConfig.cmake from ./CMakeLists.txt -> ./cmake/modules/CMakeLists.txt.

This matches LLVM.

llvm-svn: 274157

Summary: Take advantage of FCmpInst::Predicate's bit pattern and handle (fcmp *, x, y) | (fcmp *, x, y) and (fcmp *, x, y) & (fcmp *, x, y) more consistently. Also fold more FCmpInst::FCMP_FALSE and FCmpInst::FCMP_TRUE to constants.

Currently InstCombine wrongly folds (fcmp ogt, x, y) | (fcmp ord, x, y) to (fcmp ogt, x, y); this patch also fixes that.

Reviewers: spatel

Subscribers: llvm-commits, iteratee, echristo

Differential Revision: http://reviews.llvm.org/D21775

llvm-svn: 274156

This removes some noise for D21775's test changes.

llvm-svn: 274155

Differential Revision:   http://reviews.llvm.org/D21846

llvm-svn: 274154