When using Visual Studio's built-in support for CMake, the CMakeSettings.json contains the build configurations (build dir, generator, toolchain, cmake variables, etc). It is specific to the build machine, therefore should not be versioned.

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

llvm-svn: 345504

This fixes PR39402. The crash was caused when dereferencing nullptr in
DumpObject and printArchiveChild.

Reviewed By: jhenderson

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

Patch by Xing GUO

llvm-svn: 345503

Patch by Joe Ranieri.

llvm-svn: 345502

This test breaks the X86 MachineVerifier. It looks like the MIR part is
completely useless.

The original author suggests that it can be removed.

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

llvm-svn: 345501

Before this change, the lowering of instructions from llvm::MCInst to
mca::Instruction was done as part of the first stage of the pipeline (i.e. the
FetchStage).  In particular, FetchStage was responsible for picking the next
instruction from the source sequence, and lower it to an mca::Instruction with
the help of an object of class InstrBuilder.

The dependency on InstrBuilder was problematic for a number of reasons. Class
InstrBuilder only knows how to lower from llvm::MCInst to mca::Instruction.
That means, it is hard to support a different scenario where instructions
in input are not instances of class llvm::MCInst. Even if we managed to
specialize InstrBuilder, and generalize most of its internal logic, the
dependency on InstrBuilder in FetchStage would have caused more troubles (other
than complicating the pipeline logic).

With this patch, the lowering step is done before the pipeline is run. The
pipeline is no longer responsible for lowering from MCInst to mca::Instruction.
As a consequence of this, the FetchStage no longer needs to interact with an
InstrBuilder. The mca::SourceMgr class now simply wraps a reference to a
sequence of mca::Instruction objects.
This simplifies the logic of FetchStage, and increases the usability of it.  As
a result, on a debug build, we see a 7-9% speedup; on a release build, the
speedup is around 3-4%.

llvm-svn: 345500

[llvm-mca][UpdateTestChecks] Don't try to align blocks that have already been subject to alignment in update_mca_test_checks.py

This fixes PR39466.

llvm-svn: 345499

llvm-svn: 345498

Summary:
I recently discovered that adding the following code into `opencl-c.h` causes
failure of `test/Headers/opencl-c-header.cl`:
```
#pragma OPENCL EXTENSION cl_my_ext : begin
void cl_my_ext_foobarbaz();
#pragma OPENCL EXTENSIOn cl_my_ext : end
```

Clang crashes at the assertion is `ASTReader::getGlobalSubmoduleID()`:
```
assert(I != M.SubmoduleRemap.end() && "Invalid index into submodule index remap");
```

The root cause of the problem that to deserialize `OPENCL_EXTENSION_DECLS`
section `ASTReader` needs to deserialize a Decl contained in it. In turn,
deserializing a Decl requires information about whether this declaration is
part of a (sub)module, but this information is not read yet because it is
located further in a module file.

Reviewers: Anastasia, yaxunl, JDevlieghere

Reviewed By: Anastasia

Subscribers: sidorovd, cfe-commits, asavonic

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

llvm-svn: 345497

Summary:
During method import we check for structural eq of two methods.
In the structural eq check we check for their isVirtual() flag. That
flag, however, may depend on the number of overrides. Before this
change we imported the overrides *after* we had imported the rest of the
redecl chain.  So, during the import of another decl from the chain
IsVirtual() gave false result.

Writing tests for this is not really possible, because there is no way
to remove an overridden method via the AST API.
(We should access the private ASTContext::OverriddenMethods container.)
Also, we should do the remove in the middle of the import process.

Reviewers: a_sidorin, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits

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

llvm-svn: 345496

This fixes PR39404.

Reviewed By: jhenderson

Patch by Xing Guo

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

llvm-svn: 345495

llvm-svn: 345493

Revert older change that was incorrect in this test.
It was already reverted in the past after an attempt to port it to Darwin.

While there, mark FreeBSD as unsupported as well.

llvm-svn: 345492

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

llvm-svn: 345491

ReadProcMaps() on NetBSD does not handle >=1MB of memory layout information.

llvm-svn: 345490

Summary:
Some cases where `postCurrentThreadFCT()` are not guarded by our
recursion guard. We've observed that sometimes these can lead to
deadlocks when some functions (like memcpy()) gets outlined and the
version of memcpy is XRay-instrumented, which can be materialised by the
compiler in the implementation of lower-level components used by the
profiling runtime.

This change ensures that all calls to `postCurrentThreadFCT` are guarded
by our thread-recursion guard, to prevent deadlocks.

Reviewers: mboerger, eizan

Subscribers: llvm-commits

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

llvm-svn: 345489

[X86] Force floating point values in constant pool decoding to print in scientific notation so they can't be confused with integers.

When the floating point constants are whole numbers they have no decimal point so look like integers, but mean something very different in something like an 'and' instruction.

Ideally we would just print a decimal point and a 0, but I couldn't see how to make APFloat::toString do that.

llvm-svn: 345488

This reverts commit r345486.

Looks like it causes some old versions of GCC to crash, I'll see if I can
work around it and recommit...

llvm-svn: 345487

This commit enables pushing an empty #pragma clang attribute push, then adding
multiple attributes to it, then popping them all with #pragma clang attribute
pop, just like #pragma clang diagnostic. We still support the current way of
adding these, #pragma clang attribute push(__attribute__((...))), by treating it
like a combined push/attribute. This is needed to create macros like:

DO_SOMETHING_BEGIN(attr1, attr2, attr3)
// ...
DO_SOMETHING_END

rdar://45496947

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

llvm-svn: 345486

Summary:
In D53560, we assumed a specific layout for memory without using an
explicit structure. This follow-up change uses more portable layout
control by using unions in a struct, and consolidating the memory
management code in the buffer queue.

We also take the opportunity to improve the documentation on the types
and operations, along with simplifying some of the logic in the buffer
queue implementation.

Reviewers: mboerger, eizan

Subscribers: jfb, llvm-commits

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

llvm-svn: 345485

llvm-svn: 345484

[X86] Add test case to show failure to handle splat vectors in the constant check in LowerFCOPYSIGN.

llvm-svn: 345483

This reverts commit 836c763dadbd9478fa35b1a291a38bf17aa206ba.  Default
initialize the values that MSAN caught.

llvm-svn: 345482

llvm-svn: 345481

Summary: SNB is the only one that has P23 as a single proc res.

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits

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

llvm-svn: 345480

We correctly handled extended vectors of non-floating point types.
However, we have the Intel style builtins which MSVC also supports which
do overlap in sizes with the floating point extended vectors.  This
would result in overloading of floating point extended vector types
which matched sizes (e.g. <3 x float> would be backed by a <4 x float>
and thus match sizes) to be mangled similarly.  Extended vectors are a
clang extension which live outside of the builtins, so mangle them all
similarly.  This change just extends the current scheme to treat
floating point types similar to the way that we treat other types
currently.

This now allows the swift runtime to be built for Windows again.

llvm-svn: 345479

[TargetLowering] Move i64/vXi64 to f32/vXf32 UINT_TO_FP handling to TargetLowering::expandUINT_TO_FP.

llvm-svn: 345478

SwitchCaseBits.CaseStmtIsGNURange needs to be initialized first.

llvm-svn: 345477

Else we are clearly testing the wrong instruction.

llvm-svn: 345476

Else we are clearly testing the wrong instruction.

llvm-svn: 345475

Else we are clearly testing the wrong instruction.

llvm-svn: 345474

Add vector support to TargetLowering::expandFP_TO_UINT.

This exposes an issue in X86TargetLowering::LowerVSELECT which was assuming that the select mask was the same width as the LHS/RHS ops - as long as the result is a sign splat we can easily sext/trunk this.

llvm-svn: 345473

Don't store the data for case statements of the form LHS ... RHS if not
needed. This cuts the size of CaseStmt by 1 pointer + 1 SourceLocation in
the common case.

Also use the newly available space in the bit-fields of Stmt to store the
keyword location of SwitchCase and move the small accessor
SwitchCase::getSubStmt to the header.

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

Reviewed By: rjmccall

llvm-svn: 345472

Summary:
This change implements the ref-counting for backing stores associated
with generational buffer management. We do this as an implementation
detail of the buffer queue, instead of exposing this to the interface.

This change allows us to keep the buffer queue interface and usage model
the same.

Depends on D53551.

Reviewers: mboerger, eizan

Subscribers: jfb, llvm-commits

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

llvm-svn: 345471

llvm-svn: 345470

Enable constant folding when both operands are vectors of constants.

Turn into FNEG/FABS when the RHS is a splat constant vector.

llvm-svn: 345469

[X86] Add test cases showing missed opportunities for optimizing vector fcopysign when the RHS is a splat constant.

llvm-svn: 345468

The change was inadvertently included in my last commit.

llvm-svn: 345467

Summary: Also fix a FIXME in _build_stage1_clang: clang llvm-profdata profile are sufficient

Reviewers: george.burgess.iv

Subscribers: llvm-commits

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

llvm-svn: 345466

This patch has caused fast-math issues in the reduction pattern.

Will re-work and land again.

llvm-svn: 345465

Only store the needed data in IfStmt. This cuts the size of IfStmt
by up to 3 pointers + 1 SourceLocation. The order of the children
is intentionally kept the same even though it would be more
convenient to put the optional trailing objects last. Additionally
use the newly available space in the bit-fields of Stmt to store
the location of the "if".

The result of this is that for the common case of an
if statement of the form:

if (some_cond)
  some_statement

the size of IfStmt is brought down to 8 bytes + 2 pointers,
instead of 8 bytes + 5 pointers + 2 SourceLocation.

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

Reviewed By: rjmccall

llvm-svn: 345464