Replace const char pointers with llvm::StringRef and use its equality
operator for string comparisons.

llvm-svn: 334631

On Windows we've observed that if you open a file, write to it, map it into
memory and close the file handle, the contents of the memory mapping can
sometimes be incorrect. That was what we did when adding an entry to the
ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing
intermittent build failures on Chromium's ThinLTO bots on Windows. More
details are in the associated Chromium bug (crbug.com/786127).

We can prevent this from happening by keeping a handle to the file open while
the mapping is active. So this patch changes the mapped_file_region class to
duplicate the file handle when mapping the file and close it upon unmapping it.

One gotcha is that the file handle that we keep open must not have been
created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system
will prevent other processes from opening the file. We can achieve this
by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether.  Instead,
we use SetFileInformationByHandle with FileDispositionInfo to manage the
delete-on-close bit. This lets us remove the hack that we used to use to
clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE.

A downside of using SetFileInformationByHandle/FileDispositionInfo as
opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using
CreateFile to open the file while the flag is set, even within the same
process. This doesn't seem to matter for almost every client of TempFile,
except for LockFileManager, which calls sys::fs::create_link to create a
hard link from the lock file, and in the process of doing so tries to open
the file. To prevent this change from breaking LockFileManager I changed it
to stop using TempFile by effectively reverting r318550.

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

llvm-svn: 334630

spatel noticed it was missing in D47993.

llvm-svn: 334629

https://bugs.llvm.org/show_bug.cgi?id=37778
...shows a miscompile resulting from marking nan builtins as 'const'.

The nan libcalls/builtins take a pointer argument:
http://www.cplusplus.com/reference/cmath/nan-function/
...and the chars dereferenced by that arg are used to fill in the NaN constant payload bits.

"const" means that the pointer argument isn't dereferenced. That's translated to "readnone" in LLVM.
"pure" means that the pointer argument may be dereferenced. That's translated to "readonly" in LLVM.

This change prevents the IR optimizer from killing the lead-up to the nan call here:

double a() {
  char buf[4];
  buf[0] = buf[1] = buf[2] = '9';
  buf[3] = '\0';
  return __builtin_nan(buf);
}

...the optimizer isn't currently able to simplify this to a constant as we might hope, 
but this patch should solve the miscompile.

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

llvm-svn: 334628

Use `\brief` instead of `\Brief`.  NFC.

llvm-svn: 334627

It seems to be passing, at least on the bots I've seen.

llvm-svn: 334626

Currently the handle type is a global pointer which holds 8 bytes.
We need a larger type which hold 16 bytes, therefore change it
to [i64 x 2].

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

llvm-svn: 334625

Summary:
Move madvise(MADV_NOHUGEPAGE) for the meta shadow memory after the meta
shadow memory is mapped (currently it silently fails with ENOMEM).

Add a diagnostic message to detect similar problems in the future.

Reviewers: dvyukov

Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits

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

llvm-svn: 334624

[CostModel][X86] Test showing failure to recognise REVERSE shuffle mask if the elements come from the second src

llvm-svn: 334623

See bug 37566: https://bugs.llvm.org/show_bug.cgi?id=37566

Reviewers: artem.tamazov, arsenm, nhaehnle

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

llvm-svn: 334622

llvm-svn: 334620

Just use field initializers that don't suffer from this problem

llvm-svn: 334619

As noted by Pavel on lldb-commits, we don't need the temp path, we can
just pass the filename directly into extension() and path().

llvm-svn: 334618

Not sure why, but it breaks buildbot clang-cmake-armv8-full.
It causes a failure in TEST 'Xray-armhf-linux :: TestCases/Posix/profiling-single-threaded.cc'.

llvm-svn: 334617

[CostModel][X86] Test showing failure to recognise BROADCAST shuffle mask if the elements come from the second src

llvm-svn: 334616

With the recent changes in FileSpec to use LLVM's path style, it is
possible to delegate a bunch of common path operations to LLVM's path
helpers. This means we only have to maintain a single implementation and
at the same time can benefit from the efforts made by the rest of the
LLVM community.

This is part one of a set of patches. There was no obvious way to split
this so I just worked from top to bottom.

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

llvm-svn: 334615

llvm-svn: 334614

Diasble the use of the type __float128 for PPC machines older
than Power9.

The use of -mfloat128 for PPC machine older than Power9 will result
in an error.

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

llvm-svn: 334613

Fixes a build bot breakage caused by r334593.

llvm-svn: 334612

Summary:
This patch adds a modulemap which allows compiling the lldb headers into C++ modules
(for example in builds with LLVM_ENABLE_MODULES=On).

Even though most of the affected code has been cleaned up to work with the more strict
C++ module semantics, there are still some workarounds left in the current modulemap
(the most obvious one is the big `lldb` wrapper module).

It also moves the Obj-C++ files in lldb to their own subdirectories. This was necessary
because we need to filter out the modules flags for this code.

Note: With the latest clang and libstdc++ it seems necessary to have a STL C++ module
to get a working LLVM_ENABLE_MODULES build for lldb. Otherwise clang will falsely
detect ODR violations in the textually included STL code inside the lldb modules.

Reviewers: aprantl, bruno

Reviewed By: aprantl, bruno

Subscribers: mgorny, yamaguchi, v.g.vassilev, lldb-commits

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

llvm-svn: 334611

llvm-svn: 334610

See bug 37653: https://bugs.llvm.org/show_bug.cgi?id=37653

Reviewers: artem.tamazov, arsenm

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

llvm-svn: 334609

We're constant folding here, so we shouldn't check uses. This matches
the IR optimizer behavior.

The x86 test shows the expected win. The AArch64 test shows something
else. This only seems to happen if the "generic" AArch64 CPU model is 
used by MachineCombiner, so I'll file a bug report to follow-up.

llvm-svn: 334608

Summary:
The code that handles ISD:Register and ISD::CopyFromReg assumes
the target is amdgcn, so this is broken on r600.  We don't
need this analysis on r600 anyway so we can safely move
it to SITargetLowering.

Reviewers: alex-t, arsenm, nhaehnle

Reviewed By: arsenm

Subscribers: msearles, kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 334607

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/31500

llvm-svn: 334606

The equivalent AArch64 test added at rL334556 isn't showing
the expected output from the DAGCombiner code change that 
would fix this example. That's a machine combiner bug from 
what I see.

llvm-svn: 334605

ExprMutationAnalyzer is a generally useful helper that can be used in different clang-tidy checks for checking whether a given expression is (potentially) mutated within a statement (typically the enclosing compound statement.) This is a more general and more powerful/accurate version of isOnlyUsedAsConst, which is used in ForRangeCopyCheck, UnnecessaryCopyInitialization.

Patch by Shuai Wang

llvm-svn: 334604

Add a helper function to expand constrained FP operations as needed. 
Note that the Strict POWI operation is not handled in this patch since 
the format is slightly different from the others.

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

llvm-svn: 334603

Even if we support no-canonical-prefix on
clang-cl(https://reviews.llvm.org/D47480), argv0 becomes absolute path
in clang-cl and that embeds absolute path in /showIncludes.

This patch removes such full path normalization from InitLLVM on
windows, and that removes absolute path from clang-cl output
(obj/stdout/stderr) when debug flag is disabled.

Patch by Takuto Ikuta!

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

llvm-svn: 334602

Reviewers: courbet

Reviewed By: courbet

Subscribers: tschuett, llvm-commits

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

llvm-svn: 334601

Summary:
 In many cases we can't devirtualize
 because definition of vtable is not present. Most of the
 time it is caused by inline virtual function not beeing
 emitted. Forcing emitting of vtable adds a reference of these
 inline virtual functions.
 Note that GCC was always doing it.

Reviewers: rjmccall, rsmith, amharc, kuhar

Subscribers: llvm-commits, cfe-commits

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



Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com>
llvm-svn: 334600

Reviewers: courbet

Subscribers: tschuett, llvm-commits

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

llvm-svn: 334599

This reverts r334594, it breaks buildbots and fails with expensive checks.

llvm-svn: 334598

Enable these builtins to be called across a lambda
boundary with captureless const/constexpr, as brought up by 
Eli here: https://reviews.llvm.org/D48040

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

llvm-svn: 334597

Summary: Previous design was relying on the 'mutate' keyword and was quite confusing. This version separate mutable from immutable data and makes it clearer what changes and what doesn't.

Reviewers: courbet

Subscribers: tschuett, llvm-commits

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

llvm-svn: 334596

Author: milena.vujosevic.janicic
Reviewers: sdardis
The patch extends size reduction pass for MicroMIPS.
It introduces reduction of two instructions into one instruction:
Two SW instructions are transformed into one SWP instrucition.
Two LW instructions are transformed into one LWP instrucition.
Differential Revision: https://reviews.llvm.org/D39115

llvm-svn: 334595

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

llvm-svn: 334594

Follow up for D41537 - libclang part.

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

llvm-svn: 334593

This shortcoming was noted in D47330, and the test diffs show we already 
had other examples where we failed to fold to a SHRUNKBLEND:

/// Dynamic (non-constant condition) vector blend where only the sign bits
/// of the condition elements are used. This is used to enforce that the
/// condition mask is not valid for generic VSELECT optimizations.

This patch implements an idea from D48043 and would obsolete that patch 
because it catches more cases (notable the AVX1 case that was missed there). 
All we're doing is allowing the existing transform to fire more often by 
removing the post-legalize constraint. All of the relevant feature checks 
and other predicates are left as-is.

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

llvm-svn: 334592

Fences are inserted according to table A.6 in the current draft of version 2.3
of the RISC-V Instruction Set Manual, which incorporates the memory model
changes and definitions contributed by the RISC-V Memory Consistency Model
task group.

Instruction selection failures will now occur for 8/16/32-bit atomicrmw and 
cmpxchg operations when targeting RV32IA until lowering for these operations 
is added in a follow-on patch.

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

llvm-svn: 334591