directly walks the current loop structure verifying that a matching
structure can be found in a freshly computed version.

Also pull things out of containers when necessary once an issue is found
and print them directly.

This makes it substantially easier to debug verification failures as
the process stops at the exact point in the loop nest where they diverge
and has in easily accessed local variables (or printed to stderr
already) the loops and other information needed to analyze the failure.

Differential Revision: https://reviews.llvm.org/D29142

llvm-svn: 293133

Now we never append a number to the file name for task ID 0.

Differential Revision: https://reviews.llvm.org/D29160

llvm-svn: 293132

llvm-svn: 293131

llvm-svn: 293130

llvm-svn: 293129

llvm-svn: 293128

llvm-svn: 293127

llvm-svn: 293126

[libFuzzer] simplify the code for __sanitizer_cov_trace_pc_guard and make sure it is not asan/msan-instrumented

llvm-svn: 293125

Even when we don't create a remainder loop (that is, when we unroll by 2), we
may duplicate nested loops into the remainder. This is complicated by the fact
the remainder may itself be either inserted into an outer loop, or at the top
level. In the latter case, we may need to create new top-level loops.

Differential Revision: https://reviews.llvm.org/D29156

llvm-svn: 293124

Rather than storing a single flat list of SourceLocations where the diagnostic
state changes (in source order), we now store a separate list for each FileID
in which there is a diagnostic state transition. (State for other files is
built and cached lazily, on demand.) This has two consequences:

1) We can now sensibly support modules, and properly track the diagnostic state
for modular headers (this matters when, for instance, triggering instantiation
of a template defined within a module triggers diagnostics).

2) It's much faster than the old approach, since we can now just do a binary
search on the offsets within the FileID rather than needing to call
isBeforeInTranslationUnit to determine source order (which is surprisingly
slow). For some pathological (but real world) files, this reduces total
compilation time by more than 10%.

For now, the diagnostic state points for modules are loaded eagerly. It seems
feasible to defer this until diagnostic state information for one of the
module's files is needed, but that's not part of this patch.

llvm-svn: 293123

Otherwise we ask for a domtree node that's not there, and we crash.

Differential Revision:  https://reviews.llvm.org/D29145

llvm-svn: 293122

This is the opt/llc counterpart of -fsave-optimization-record to output
optimization remarks in a YAML file.

llvm-svn: 293121

Thanks to Dave Lee for pointing this out!

llvm-svn: 293120

Thanks to Davide Italiano for finding the problem and providing a test case.

llvm-svn: 293119

llvm-svn: 293117

Summary: Fix comments in response to jlebar's comments in D27872.

Reviewers: jlebar

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D29109

llvm-svn: 293116

Summary:
Previously we assumed that the result of sqrt(x) always had 0 as its
sign bit.  But sqrt(-0) == -0.

Reviewers: hfinkel, efriedma, sanjoy

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D28928

llvm-svn: 293115

the clang-x86-windows-msvc2015 bot as the name is "llvm-nm.EXE" in that case.

llvm-svn: 293114

Analogous to the code in opt, this enables hotness in opt-remarks.

llvm-svn: 293113

llvm-svn: 293112

pointers are 4-bytes instead of 8-bytes.

llvm-svn: 293111

This allows MIR passes to emit optimization remarks with the same level
of functionality that is available to IR passes.

It also hooks up the greedy register allocator to report spills.  This
allows for interesting use cases like increasing interleaving on a loop
until spilling of registers is observed.

I still need to experiment whether reporting every spill scales but this
demonstrates for now that the functionality works from llc
using -pass-remarks*=<pass>.

Differential Revision: https://reviews.llvm.org/D29004

llvm-svn: 293110

Code region is the only part of this class that is IR-specific.  Code
region is moved down in the inheritance tree to a new derived class,
called DiagnosticInfoIROptimization.

All the existing remarks are derived from this new class now.

This allows the new MIR pass-remark classes to be derived from
DiagnosticInfoOptimizationBase.

Also because we keep the name DiagnosticInfoOptimizationBase, the clang
parts don't need any adjustment.

Differential Revision: https://reviews.llvm.org/D29003

llvm-svn: 293109

Bots were failing because some targets emit signext before i32.

llvm-svn: 293108

Summary: MSVC allows linker options to be specified in source code. One of these is the /INCLUDE directive, which specifies that a symbol must be added to the symbol table, even if it otherwise wouldn't be. Existing tests cover the case where the linker is given an object file with an /INCLUDE directive, but we also need to cover the case where /INCLUDE is specified in a bitcode file (as would happen when using LTO). This new test covers that case.

Reviewers: pcc, ruiu

Reviewed By: ruiu

Differential Revision: https://reviews.llvm.org/D29096

llvm-svn: 293107

in the current lexical scope.

clang currently emits the lifetime.start marker of a variable when the
variable comes into scope even though a variable's lifetime starts at
the entry of the block with which it is associated, according to the C
standard. This normally doesn't cause any problems, but in the rare case
where a goto jumps backwards past the variable declaration to an earlier
point in the block (see the test case added to lifetime2.c), it can
cause mis-compilation.

To prevent such mis-compiles, this commit conservatively disables
emitting lifetime variables when a label has been seen in the current
block.

This problem was discussed on cfe-dev here: 
http://lists.llvm.org/pipermail/cfe-dev/2016-July/050066.html

rdar://problem/30153946

Differential Revision: https://reviews.llvm.org/D27680

llvm-svn: 293106

llvm-svn: 293105

This eliminates one overload on the term Raw.

Differential Revision: https://reviews.llvm.org/D29098

llvm-svn: 293104

llvm-svn: 293102

Document the current practice regarding dropping metadata on modules,
functions and global variables.

Differential Revision: https://reviews.llvm.org/D29110

llvm-svn: 293101

llvm-svn: 293100

Mach-O files don’t have size information about the symbols in the object file
format unlike ELF.

Also add the part of the fix to llvm-nm that was missed with r290001 so
-arch armv7m works.

rdar://25681018

llvm-svn: 293099

debugserver-mini can't use Foundation so disable that code there. 

llvm-svn: 293098

Summary:
Now when you ask clang to link in a bitcode module, you can tell it to
set attributes on that module's functions to match what we would have
set if we'd emitted those functions ourselves.

This is particularly important for fast-math attributes in CUDA
compilations.

Each CUDA compilation links in libdevice, a bitcode library provided by
nvidia as part of the CUDA distribution.  Without this patch, if we have
a user-function F that is compiled with -ffast-math that calls a
function G from libdevice, F will have the unsafe-fp-math=true (etc.)
attributes, but G will have no attributes.

Since F calls G, the inliner will merge G's attributes into F's.  It
considers the lack of an unsafe-fp-math=true attribute on G to be
tantamount to unsafe-fp-math=false, so it "merges" these by setting
unsafe-fp-math=false on F.

This then continues up the call graph, until every function that
(transitively) calls something in libdevice gets unsafe-fp-math=false
set, thus disabling fastmath in almost all CUDA code.

Reviewers: echristo

Subscribers: hfinkel, llvm-commits, mehdi_amini

Differential Revision: https://reviews.llvm.org/D28538

llvm-svn: 293097

llvm-svn: 293096

llvm-svn: 293095

This is the patch upstreaming the device-agnostic part of libomptarget.

Differential Revision: https://reviews.llvm.org/D14031

llvm-svn: 293094

It now uses the same infrastructure as symbol versions. This fixes us
creating a dynamic relocation without a corresponding dynamic symbol.

This also means that unlike gold and bfd we keep a STB_LOCAL in the
static symbol table. It seems an odd feature to offer precise control
over what is in a symbol table that is not used by the dynamic
linker. We can bring this back if needed, but it would probably be
better to just have --discard option that tells the linker to keep in
the static symbol table only what is in the dynamic one.

Should fix the eog build.

llvm-svn: 293093

This reverts commit r292680. It is causing significantly worse
performance and test timeouts in our internal builds. I have already
routed reproduction instructions your way.

llvm-svn: 293092