This fixes host-side LTO during CUDA compilation. Before, LTO
pipeline construction was clashing with CUDA pipeline construction.

At the moment there's no point doing LTO on device side as each
device-side TU is a complete program.  We will need to figure out
compilation pipeline construction for the device-side LTO when we
have working support for multi-TU device-side CUDA compilation.

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

llvm-svn: 328161

llvm-svn: 328160

This is basically an extension of existing test
test/CodeGen/X86/O0-pipeline.ll introduced in r302608.

llvm-svn: 328159

This is needed for the upcoming implementation of the
new 8x32x16 and 32x8x16 variants of WMMA instructions
introduced in CUDA 9.1.

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

llvm-svn: 328158

Lit automatically rewrites /dev/null to a temp file on Windows.

llvm-svn: 328157

llvm-svn: 328156

The "ShouldEmitMatchRegisterName" bit wasn't taking effect because the
WebAssembly target didn't point to the custom WebAssemblyAsmParser
record.

llvm-svn: 328155

This is mostly just plumbing to get a DWARFDataExtractor where we
compute abbr_offset so we can use getRelocatedValue.

This is part of PR36793.

llvm-svn: 328154

During reading C++ definition data for lambda we can access
CXXRecordDecl representing lambda before we finished reading the
definition data. This can happen by reading a captured variable which is
VarDecl, then reading its decl context which is CXXMethodDecl `operator()`,
then trying to merge redeclarable methods and accessing
enclosing CXXRecordDecl. The call stack looks roughly like

    VisitCXXRecordDecl
      ReadCXXRecordDefinition
        VisitVarDecl
          VisitCXXMethodDecl
            mergeRedeclarable
              getPrimaryContextForMerging

If we add fake definition data at this point, later we'll hit the assertion

    Assertion failed: (!DD.IsLambda && !MergeDD.IsLambda && "faked up lambda definition?"), function MergeDefinitionData, file clang/lib/Serialization/ASTReaderDecl.cpp, line 1675.

The fix is to assign definition data before reading it. Fixes PR32556.

rdar://problem/37461072

Reviewers: rsmith, bruno

Reviewed By: rsmith

Subscribers: cfe-commits, jkorous-apple, aprantl

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

llvm-svn: 328153

There are at least 3 problems:
1. We're distributing across large patterns, but fail to do that for the minimal patterns.
2. We're not checking uses, so we may create more instructions than we eliminate.
3. We should be able to do these transforms with less than full 'fast' fmuls.

llvm-svn: 328152

Summary:
Following-up the refactoring of mmap interceptors, adding a new common
option to detect PROT_WRITE|PROT_EXEC pages request.

Patch by David CARLIER

Reviewers: vitalybuka, vsk

Reviewed By: vitalybuka

Subscribers: krytarowski, #sanitizers

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

llvm-svn: 328151

Fixing the the failing Windows tests.

llvm-svn: 328150

llvm-svn: 328149

Summary: The global stack initialization function may be called multiple times. The initialization of the shared memory slots should only happen when the function is called for the first time for a given warp master thread.

Reviewers: grokos, carlo.bertolli, ABataev, caomhin

Reviewed By: grokos

Subscribers: guansong, openmp-commits

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

llvm-svn: 328148

llvm-svn: 328147

Summary: The check for the master warp must take into consideration the actual number of warps: the master warp is equal to the last active warp not necessarily WARPSIZE - 1.

Reviewers: grokos, carlo.bertolli, ABataev, caomhin

Reviewed By: grokos

Subscribers: guansong, openmp-commits

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

llvm-svn: 328146

This asserts when compiling safe_numerics_unittest.cpp in Chromium with
MSan.

llvm-svn: 328145

Summary:
This patch allows worker to have a global memory stack managed by the runtime. This patch is needed for completeness and consistency with the globalization policy: if a worker-side variable escapes the current context it then needs to be globalized.
Until now, only the master thread was allowed to have such a stack. These global values can now potentially be shared amongst workers if the semantics of the OpenMP program require it.

Reviewers: ABataev, grokos, carlo.bertolli, caomhin

Reviewed By: grokos

Subscribers: guansong, openmp-commits

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

llvm-svn: 328144

This diff adds support for SHT_GROUP sections to llvm-objcopy.
Some sections are interrelated and comprise a group.
For example, a definition of an inline function might require, 
in addition to the section containing its instructions, 
a read-only data section containing literals referenced inside the function.
A section of the type SHT_GROUP contains the indices of the group members,
therefore, it needs to be updated whenever the indices change.
Similarly, the fields sh_link, sh_info should be recalculated as well.

[Resubmit r328012 with the proper handling of endianness]

Test plan: make check-all

Differential revision: https://reviews.llvm.org/D43996

llvm-svn: 328143

[TableGen] Hoist the code for copying InstRWs from an old scheduling class to a new one out of the loop that assigns instructions to the new class. NFCI

We already know all the of instructions we're processing in the instruction loop belong to no class or all to the same class. So we only have to worry about remapping one class. So hoist it all out and remove the SmallPtrSet that tracked which class we'd already remapped.

I had to introduce new instruction loop inside this code to print an error message, but that only occurs on the error path.

llvm-svn: 328142

llvm-svn: 328141

We propagate the existing NaN value when possible.

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

llvm-svn: 328140

We already have an OldSCIdx variable in the outer loop here. And we already did the map lookup in the loop that populated ClassInstrs. And the outer OldSCIdx got it from ClassInstrs.

llvm-svn: 328139

llvm-svn: 328138

llvm-svn: 328137

[X86] Rewrite getOperandBias in X86BaseInfo.h to be a little more structured and update comments to be more clear about what it does. NFC

llvm-svn: 328136

Sink Analysis/ObjectUtil(canBeOmittedFromSymbolTable) into IR so it can be legitimately be used by Object/IRSymtab

llvm-svn: 328135

[Builtins] Overload __builtin_operator_new/delete to allow forwarding to usual allocation/deallocation functions.

Summary:
Libc++'s default allocator uses `__builtin_operator_new` and `__builtin_operator_delete` in order to allow the calls to new/delete to be ellided. However, libc++ now needs to support over-aligned types in the default allocator. In order to support this without disabling the existing optimization Clang needs to support calling the aligned new overloads from the builtins.

See llvm.org/PR22634 for more information about the libc++ bug.

This patch changes `__builtin_operator_new`/`__builtin_operator_delete` to call any usual `operator new`/`operator delete` function. It does this by performing overload resolution with the arguments passed to the builtin to determine which allocation function to call. If the selected function is not a usual allocation function a diagnostic is issued.

One open issue is if the `align_val_t` overloads should be considered "usual" when `LangOpts::AlignedAllocation` is disabled.


In order to allow libc++ to detect this new behavior the value for `__has_builtin(__builtin_operator_new)` has been updated to `201802`.

Reviewers: rsmith, majnemer, aaron.ballman, erik.pilkington, bogner, ahatanak

Reviewed By: rsmith

Subscribers: cfe-commits

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

llvm-svn: 328134

llvm-svn: 328133

Summary:
External functions appearing as indirect call targets could not be
found in the SymTab, and the value:counter record was represented,
in the text format, using an empty string for the name. This would
then cause a silent parsing error when reading.

This CL:
- adds explicit support for such functions
- fixes the places where we would not propagate errors when reading
- addresses a performance issue due to eager resorting of the SymTab.

Reviewers: xur, eraman, davidxl

Reviewed By: davidxl

Subscribers: llvm-commits

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

llvm-svn: 328132

Adding the config initialization to clang-tools-extra so that tests that
use REQUIRES, UNSUPPORTED, and XFAIL based on platform or target triple
work properly.

llvm-svn: 328131

llvm-svn: 328130

With this patch, the "instruction dispatched" event now provides information
related to the number of microarchitectural registers used in each register
file. Similarly, the "instruction retired" event is now able to tell how may
registers are freed in each register file.

Currently, the BackendStatistics view is the only consumer of register
usage/pressure information. BackendStatistics uses that info to print out a few
general statistics (i.e. max number of mappings used; total mapping created).
Before this patch, the BackendStatistics was forced to query the Backend to
obtain the register pressure information.

This helps removes that dependency. Now views are completely independent from
the Backend.  As a consequence, it should be easier to address PR36663 and
further modularize the pipeline.

Added a couple of test cases in the BtVer2 specific directory.

llvm-svn: 328129

llvm-svn: 328128

After changes to lit.site.cfg.in, the test is now running (and failing)
on windows, so temporarily marking it unsupported. See PR36855 for more
details.

llvm-svn: 328127

llvm-svn: 328126

llvm-svn: 328125

I didn't mean to commit it, but I guess I failed to switch branches or stash it in my local tree.

llvm-svn: 328124

Compiler.h is used by Demangle (which Support depends on) - so sink it
into Demangle to avoid a circular dependency

DataTypes.h is used by llvm-c (which Support depends on) - so sink it
into llvm-c.

DataTypes.h could probably be fixed the other way - making llvm-c depend
on Support instead of Support depending on llvm-c - if anyone feels
that's the better option, happy to work with them on that.

I /think/ this'll address the layering issues that previous attempts to
commit this have triggered in the Modules buildbot, but I haven't been
able to reproduce that build so can't say for sure. If anyone's having
trouble with this - it might be worth taking a look to see if there's a
quick fix/something small I missed rather than revert, but no worries.

llvm-svn: 328123

llvm-svn: 328122