[EfficiencySanitizer] [MIPS64] Enables esan clang driver options for MIPS64

Reviewed by bruening
Differential: D23800

llvm-svn: 280806

Enable test on windows.

It looks like it was disable just because we were missing a demangler.

llvm-svn: 280805

[InstCombine][SSE4a] Fix assertion failure caused by unsafe dyn_casts on the operands of extrq/extrqi intrinsic calls.

This patch fixes an assertion failure caused by unsafe dynamic casts on the
constant operands of sse4a intrinsic calls to extrq/extrqi

The combine logic that simplifies sse4a extrq/extrqi intrinsic calls currently
checks if the input operands are constants. Internally, that logic relies on
dyn_casts of values returned by calls to method Constant::getAggregateElement.
However, method getAggregateElemet may return nullptr if the constant element
cannot be retrieved. So, all the dyn_casts can potentially fail. This is what
happens for example if a constexpr value is passed in input to an extrq/extrqi
intrinsic call.

This patch fixes the problem by using a dyn_cast_or_null (instead of a simple
dyn_cast) on the result of each call to Constant::getAggregateElement.

Added reproducible test cases to x86-sse4a.ll.

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

llvm-svn: 280804

[ELF] - Sort command line options. NFC.

llvm-svn: 280803

Revert "[EfficiencySanitizer] Adds shadow memory parameters for 40-bit virtual memory address."

This reverts commit r280796, as it broke the AArch64 bots for no reason.

The tests were passing and we should try to keep them passing, so a proper
review should make that happen.

llvm-svn: 280802

[ELF] - Linkerscript: create multiple output sections for inputs with different attributes.

Previously we combined sections by name if linkerscript was used.
For that we had to disable SHF_MERGE handling temporarily, but then
found that implementing it properly will require additional complexity layers like
subsections or something.
At the same time looks we can live with multiple output sections approach for now.
That patch do this change.

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

llvm-svn: 280801

[OpenCL] Fix pipe built-in functions return type.

By default return type of call expressions calling built-in
functions is set to bool.

Fixes https://llvm.org/bugs/show_bug.cgi?id=30219.

Reviewers: Anastasia

Subscribers: dmitry, cfe-commits, yaxunl

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

llvm-svn: 280800

[ELF] - Fix for: PR29093 - version script does not support [chars] wildcards

GNU ld supports [chars] wildcards in version scripts, to match a single instance of any of the chars.
Here is an extern example from libstdc++'s version script in FreeBSD:

extern "C++"
{
...

std::locale::_[T-Za-z]*;
std::[A-Zm]*;
std::n[^u]*;
std::nu[^m]*;
std::num[^e]*;
...

}

Patch adds support for scripts above. This is PR29093.

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

llvm-svn: 280799

[mips] Disable the TImode shift libcalls for 32-bit targets.

Summary:
The o32 ABI doesn't not support the TImode helpers. For the time being,
disable just the shift libcalls as they break recursive builds on MIPS.

Reviewers: sdardis

Subscribers: llvm-commits, sdardis

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

llvm-svn: 280798

[ELF] - Enable testcases that uses demangler to run under windows and escape quotes around "C++".

Previously testcases were enabled only for shell.
r280733 added c++ itanium demangler to lld and we can enable them fully.

Also this change make quotes to be escaped:

extern "C++" -> extern \"C++\", which worked before just because we are dropping tokens
quotes internally at this moment.

llvm-svn: 280797

[EfficiencySanitizer] Adds shadow memory parameters for 40-bit virtual memory address.

Adding 40-bit shadow memory parameters because MIPS64 uses 40-bit virtual memory addresses.

Reviewed by bruening
Differential: D23801

llvm-svn: 280796

[ESan][MIPS] Adds support for MIPS64

With this patch 10 out of 13 tests are passing.

Following is the list of failing tests:

    struct-simple.cpp
    workingset-signal-posix.cpp
    mmap-shadow-conflict.c

Reviewed by bruening
Differential: D23799

llvm-svn: 280795

[SimplifyCFG] Followup fix to r280790

In failure cases it's not guaranteed that the PHI we're inspecting is actually in the successor block! In this case we need to bail out early, and never query getIncomingValueForBlock() as that will cause an assert.

llvm-svn: 280794

Fix unittest compilation on windows

After the reformat, the unittests do not compile due to missing due to redefinition errors
between PosixApi.h and ucrt/direct.h. This is a bit of a shot in the dark, as I have not tested
it on windows, but I am restoring the original include order, so it should hopefully fix it.

llvm-svn: 280793

[SimplifyCFG] Update workaround for PR30188 to also include loads

I should have realised this the first time around, but if we're avoiding sinking stores where the operands come from allocas so they don't create selects, we also have to do the same for loads because SROA will be just as defective looking at loads of selected addresses as stores.

Fixes PR30188 (again).

llvm-svn: 280792

[CMake] Use CMake's default RPATH for the unit tests

In the top-level CMakeLists.txt, we set CMAKE_BUILD_WITH_INSTALL_RPATH to ON,
and then for the unit tests we set it to <test>/../../lib. This works for tests
that live in unittest/<whatever>, but not for those that live in subdirectories
e.g. unittest/Transforms/IPO or unittest/ExecutionEngine/Orc. When building
with BUILD_SHARED_LIBRARIES, such tests don't manage to find their libraries.

Since the tests are run from the build directory, it makes sense to set their
RPATH for the build tree, rather than the install tree. This is the default in
CMake since 2.6, so all we have to do is set CMAKE_BUILD_WITH_INSTALL_RPATH to
OFF for the unit tests.

llvm-svn: 280791

[SimplifyCFG] Check PHI uses more accurately

PR30292 showed a case where our PHI checking wasn't correct. We were checking that all values were used by the same PHI before deciding to sink, but we weren't checking that the incoming values for that PHI were what we expected. As a result, we had to bail out after block splitting which caused us to never reach a steady state in SimplifyCFG.

Fixes PR30292.

llvm-svn: 280790

[PowerPC] Fix address-offset folding for plain addi

When folding an addi into a memory access that can take an immediate offset, we
were implicitly assuming that the existing offset was zero. This was incorrect.
If we're dealing with an addi with a plain constant, we can add it to the
existing offset (assuming that doesn't overflow the immediate, etc.), but if we
have anything else (i.e. something that will become a relocation expression),
we'll go back to requiring the existing immediate offset to be zero (because we
don't know what the requirements on that relocation expression might be - e.g.
maybe it is paired with some addis in some relevant way).

On the other hand, when dealing with a plain addi with a regular constant
immediate, the alignment restrictions (from the TOC base pointer, etc.) are
irrelevant.

I've added the test case from PR30280, which demonstrated the bug, but also
demonstrates a missed optimization opportunity (i.e. we don't need the memory
accesses at all).

Fixes PR30280.

llvm-svn: 280789

Support ABSOLUE keyword in symbol assignments

This patch allows making section defined symbols absolute:
.foo : {
  begin_foo = ABSOLUTE(.);
  *(.foo)
}

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

llvm-svn: 280788

OpenCL: Defining __ENDIAN_LITTLE__ and fix target endianness

OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets.
The default for targets was also apparently big endian, so AMDGPU
was incorrectly reported as big endian. Set this from the triple
so targets don't have another place to set the endianness.

llvm-svn: 280787

Fix whitespace issues

^M and extra space

llvm-svn: 280786

AVX512F: FMA intrinsic + FNEG - sequence optimization

The previous commit (r280368 - https://reviews.llvm.org/D23313) does not cover AVX-512F, KNL set.
FNEG(x) operation is lowered to (bitcast (vpxor (bitcast x), (bitcast constfp(0x80000000))).
It happens because FP XOR is not supported for 512-bit data types on KNL and we use integer XOR instead.
I added pattern match for integer XOR.

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

llvm-svn: 280785

AMDGPU: Make some scalar instructions commutable

llvm-svn: 280784

Remove unnecessary call to getAllocatableRegClass

This reapplies r252565 and r252674, effectively reverting r252956.

This allows VS_32/VS_64 to be unallocatable like they should be.

llvm-svn: 280783

[X86] Add hasSideEffects=0 to some instructions.

llvm-svn: 280782

[AVX-512] Add support for commuting masked instructions in findCommutedOpIndices. The default implementation doesn't skip the mask input or the preserved input.

llvm-svn: 280781

Avoid compile error by giving the test type a user defined default constructor

llvm-svn: 280780

Fix PR#30303 - no matching function for call to '__ptr_in_range'

llvm-svn: 280779

Revert "CodeGen: ensure that libcalls are always AAPCS CC"

This reverts SVN r280683.  Revert until I figure out why this is breaking lli
tests.

llvm-svn: 280778

Improve constexpr tests for std::any

llvm-svn: 280777

Fix clang's handling of the copy performed in the second phase of class
copy-initialization. We previously got this wrong in a couple of ways:
 - we only looked for copy / move constructors and constructor templates for
   this copy, and thus would fail to copy in cases where doing so should use
   some other constructor (but see core issue 670),
 - we mishandled the special case for disabling user-defined conversions that
   blocks infinite recursion through repeated application of a copy constructor
   (applying it in slightly too many cases) -- though as far as I can tell,
   this does not ever actually affect the result of overload resolution, and
 - we misapplied the special-case rules for constructors taking a parameter
   whose type is a (reference to) the same class type by incorrectly assuming
   that only happens for copy/move constructors (it also happens for
   constructors instantiated from templates and those inherited from base
   classes).

These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.

llvm-svn: 280776

Fix PR30260 - optional<const T> not working.

This patch fixes PR30260 by using a (void*) cast on the placement argument
to placement new to casts away the const. See also http://llvm.org/PR30260.

As a drive by change this patch also changes the header guard for
<experimental/optional> to _LIBCPP_EXPERIMENTAL_OPTIONAL from _LIBCPP_OPTIONAL.

llvm-svn: 280775

Fix typo in comment, NFC

llvm-svn: 280774

Enable installation of libc++experimental by default.

When libc++experimental was originally created it was empty and therefore there
was no reason to install it. Now that the library contains
<experimental/memory_resource> and <experimental/filesystem> there is a good
reason to install it.

Specifically this patch enables the installation whenever LIBCXX_INSTALL_LIBRARY
is true and LIBCPP_ENABLE_EXPERIMENTAL_LIBRARY is true.

llvm-svn: 280773

[LTO] Rename variables to be more explicative.

Thanks to Mehdi for the suggestion!

llvm-svn: 280772

Improve CMake output when registering benchmarks

llvm-svn: 280771

[opt] Remove an unused argument to runPassPipeline().

I have plans to use this API also in libLTO (and maybe lld).

llvm-svn: 280770

Re-add "Make FieldList records print as a YAML sequence"

This was originally submitted in r280549, and reverted in r280577
due to breaking one MSVC buildbot.  The issue is that MSVC 2013
doesn't synthesize move constructors.  So even though i was
writing std::move(A) it was copying it, leading to a bogus ArrayRef.
The solution here is to simply remove the std::vector<> from the
type, since it is unused and unnecessary.  This way the ArrayRef
continues to point into the original memory backing the CVType.

llvm-svn: 280769

[scan-build-py] Increase precision of timestamp in report directory name

This commit improves compatibility with the perl version of scan-build.

The perl version of scan-build produces output report directories with
increasing lexicographic ordering. This ordering is relied on by the CmpRuns.py
tool in utils/analyzer when comparing results for build commands with multiple
steps. That tool tries to line up the output directory for each step between
different runs of the analyzer based on the increasing directory name.

The python version of scan-build uses file.mkdtemp() with a time stamp
prefix to create report directories. The timestamp has a 1-second precision.
This means that when analysis of a single build step takes less than a second
the ordering property that CmpRuns.py expects will sometimes not hold,
depending on the timing and the random suffix generated by mkdtemp(). Ultimately
this causes CmpRuns to incorrectly correlate results from build steps and report
spurious differences between runs.

This commit increases the precision of the timestamp used in scan-build-py to
the microsecond level. This approach still has the same underlying issue -- but
in practice analysis of any build step is unlikely to take less than a
millisecond.

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

llvm-svn: 280768

[DAGCombine] More fixups to SETCC legality checking (visitANDLike/visitORLike)

I might have called this "r246507, the sequel". It fixes the same issue, as the
issue has cropped up in a few more places. The underlying problem is that
isSetCCEquivalent can pick up select_cc nodes with a result type that is not
legal for a setcc node to have, and if we use that type to create new setcc
nodes, nothing fixes that (and so we've violated the contract that the
infrastructure has with the backend regarding setcc node types).

Fixes PR30276.

For convenience, here's the commit message from r246507, which explains the
problem is greater detail:

[DAGCombine] Fixup SETCC legality checking

SETCC is one of those special node types for which operation actions (legality,
etc.) is keyed off of an operand type, not the node's value type. This makes
sense because the value type of a legal SETCC node is determined by its
operands' value type (via the TLI function getSetCCResultType). When the
SDAGBuilder creates SETCC nodes, it either creates them with an MVT::i1 value
type, or directly with the value type provided by TLI.getSetCCResultType.

The first problem being fixed here is that DAGCombine had several places
querying TLI.isOperationLegal on SETCC, but providing the return of
getSetCCResultType, instead of the operand type directly. This does not mean
what the author thought, and "luckily", most in-tree targets have SETCC with
Custom lowering, instead of marking them Legal, so these checks return false
anyway.

The second problem being fixed here is that two of the DAGCombines could create
SETCC nodes with arbitrary (integer) value types; specifically, those that
would simplify:

  (setcc a, b, op1) and|or (setcc a, b, op2) -> setcc a, b, op3
     (which is possible for some combinations of (op1, op2))

If the operands of the and|or node are actual setcc nodes, then this is not an
issue (because the and|or must share the same type), but, the relevant code in
DAGCombiner::visitANDLike and DAGCombiner::visitORLike actually calls
DAGCombiner::isSetCCEquivalent on each operand, and that function will
recognise setcc-like select_cc nodes with other return types. And, thus, when
creating new SETCC nodes, we need to be careful to respect the value-type
constraint. This is even true before type legalization, because it is quite
possible for the SELECT_CC node to have a legal type that does not happen to
match the corresponding TLI.getSetCCResultType type.

To be explicit, there is nothing that later fixes the value types of SETCC
nodes (if the type is legal, but does not happen to match
TLI.getSetCCResultType). Creating SETCCs with an MVT::i1 value type seems to
work only because, either MVT::i1 is not legal, or it is what
TLI.getSetCCResultType returns if it is legal. Fixing that is a larger change,
however. For the time being, restrict the relevant transformations to produce
only SETCC nodes with a value type matching TLI.getSetCCResultType (or MVT::i1
prior to type legalization).

Fixes PR24636.

llvm-svn: 280767

Simplify a boolean expression by using the De Morgan's law.

llvm-svn: 280766

[llvm-cov] Use colors consistently in the summary

Use the same color for counts and percentages. There doesn't seem to be
a reason for them to be different, and the summary looks more consistent
this way.

llvm-svn: 280765

[llvm-cov] Clean up the summary class, delete dead code (NFC)

llvm-svn: 280764

Revert "Fix tests on Windows."

This reverts commit 9b757b6e3946311802972409f38c6cefbea917b3.

This seems to cause strange breakages about on Ubuntu.

llvm-svn: 280763

Explicitly require DominatorTreeAnalysis pass for instsimplify pass.

Summary: DominatorTreeAnalysis is always required by instsimplify.

Reviewers: danielcdh, davidxl

Subscribers: llvm-commits

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

llvm-svn: 280760

Fix tests on Windows.

This wasn't actually a problem with the reformat, but rather a
problem with Visual Studio 2015 Update 3, which uses some c++14
features in its standard libraries.  So we had to change -std=c++11
to -std=c++14.

llvm-svn: 280759

Put the LLVM_ALIGNAS directive in the right place.

llvm-svn: 280758

Make LLDB compile on Windows after the reformat.

Most of these issues arose as a result of header re-ordering, but
it turned up a real bug, which is that MSVC doesn't support
__attribute__((packed)) or __attribute__((aligned)).  This was
working before because there's a Windows header that #defines
__attribute__(x) to nothing.  We should fix this by removing
that #define entirely, and dealing with the fallout separately
which may turn up even more bugs.

I fixed this by replacing them with the corresponding LLVM
macros which understand how to do these operations on all the
different compilers.

llvm-svn: 280757

[llvm-cov] Add the project summary to the text coverage report for each source file.

This patch is a spin-off from https://reviews.llvm.org/D23922. It extends the text view to preserve the same feature as the html view.

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

llvm-svn: 280756

Reorder FreeBSD Host.cpp #includes to fix build

llvm-svn: 280755

Try 2 - Remove <cstdlib> include from `<exception>`

This patch removes the `<cstdlib>` include from exception where it is no longer
needed. Unlike my previous attempt this patch also adds <cstdlib> where needed
in other headers like <new> and <typeinfo>.

This won't fix the Firefox build issues discussed on IRC but it is more correct
for libc++.

llvm-svn: 280754

Fix shared library build.

llvm-svn: 280753

Revert r280743 and r280745. Remove <cstdlib> include from `<exception>`

Apparently I missed a number of additional include which need to be added.
Reverting so I can recommit as a single patch with all of the required includes.

llvm-svn: 280752

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style.  This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort.  Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit.  The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

    find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
    find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit.  There are alternatives available that will attempt
to look through this change and find the appropriate prior commit.  YMMV.

llvm-svn: 280751

Avoid using alignas and constexpr.

This requires removing the custom allocator, since Demangle cannot
depend on Support and so cannot use Compiler.h.

llvm-svn: 280750

[AMDGPU] Wave and register controls

- Add missing test

llvm-svn: 280749

[CMake] Cleanup LLVM_OPTIMIZED_TABLEGEN

This cleanup removes the need for the native support library to have its own target. That target was only needed because makefile builds were tripping over each other if two tablegen targets were building at the same time. This causes problems because the parallel make invocations through CMake can't communicate with each other. This is fixed by invoking make directly instead of through CMake which is how we handle this in External Project invocations.

The other part of the cleanup is to mark the custom commands as USES_TERMINAL. This is a bit of a hack, but we need to ensure that Ninja generators don't invoke multiple tablegen targets in the same build dir in parallel, because that too would be bad.

Marking as USES_TERMINAL does have some downside for Ninja because it results in decreased parallelism, but correct builds are worth the minor loss and LLVM_OPTIMZIED_TABLEGEN is such a huge win, it is worth it.

llvm-svn: 280748

[AMDGPU] Wave and register controls

- Implemented amdgpu-flat-work-group-size attribute
- Implemented amdgpu-num-active-waves-per-eu attribute
- Implemented amdgpu-num-sgpr attribute
- Implemented amdgpu-num-vgpr attribute
- Dynamic LDS constraints are in a separate patch

Patch by Tom Stellard and Konstantin Zhuravlyov

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

llvm-svn: 280747

Try to fix a circular dependency in the modules build.

llvm-svn: 280746

Add missing <cstdlib> include. Sorry about the bot breakage

llvm-svn: 280745

AMDGPU/SI: Teach SIInstrInfo::FoldImmediate() to fold immediates into copies

Summary:
I put this code here, because I want to re-use it in a few other places.
This supersedes some of the immediate folding code we have in SIFoldOperands.
I think the peephole optimizers is probably a better place for folding
immediates into copies, since it does some register coalescing in the same time.

This will also make it easier to transition SIFoldOperands into a smarter pass,
where it looks at all uses of instruction at once to determine the optimal way to
fold operands.  Right now, the pass just considers one operand at a time.

Reviewers: arsenm

Subscribers: wdng, nhaehnle, arsenm, llvm-commits, kzhuravl

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

llvm-svn: 280744

Remove unneeded includes in <exception> after removing __libcpp_throw

llvm-svn: 280743

AMDGPU : Add XNACK feature to GPUs that support it.

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

llvm-svn: 280742

[include-fixer] Fix some Clang-tidy modernize-use-override and Include What You Use warnings; other minor fixes.

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

llvm-svn: 280741

Fix ItaniumDemangle.cpp build with MSVC 2013

llvm-svn: 280740

[llvm-cov] Add the "Go to first unexecuted line" feature.

This patch provides easy navigation to find the zero count lines, especially useful when the source file is very large.

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

llvm-svn: 280739

[SE] Rename PlatformInterfaces to PlatformDevice

Summary:
The only interface that we ever plan to have in this file is
PlatformDevice, so it makes sense to rename the file to reflect that.

Reviewers: jprice

Subscribers: parallel_libs-commits

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

llvm-svn: 280737

[AArch64] Adjust the scheduling model for Exynos M1.

Further refine the model for branches.

llvm-svn: 280736

[AArch64] Adjust the scheduling model for Exynos M1.

Further refine the model for stores.

llvm-svn: 280735

[AArch64] Adjust the scheduling model for Exynos M1.

Further refine the model for loads.

llvm-svn: 280734

Use the demangler in llvm.

llvm-svn: 280733

Add an c++ itanium demangler to llvm.

This adds a copy of the demangler in libcxxabi.

The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.

The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:

    No constexpr.
    No alignas

On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi

My current plan is:

    Commit something like this
    Change lld to use it
    Change lldb to use it as the fallback

    Add a few #ifdefs so that exactly the same file can be used in
    libcxxabi to export abi::__cxa_demangle.

Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.

llvm-svn: 280732

clang-format: [JS] whitespace required between ! and as.

Summary:
Before:
    x!as string
After:
    x! as string

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

llvm-svn: 280731

clang-format: [JS] ignore comments when wrapping returns.

Summary:
When code contains a comment between `return` and the value:

    return /* lengthy comment here */ (
        lengthyValueComesHere);

Do not wrap before the comment, as that'd break the code through JS' automatic
semicolon insertion.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

llvm-svn: 280730

[ELF] Add support for -no-gc-sections flag

This flag is supported by both BFD ld and gold and is occasionally
used to negate the effect of -gc-sections flag.

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

llvm-svn: 280729

Modules: Fix an assertion in DeclContext::buildLookup.

When calling getMostRecentDecl, we can pull in more definitions from
a module. We call getPrimaryContext afterwards to make sure that
we buildLookup on a primary context.

rdar://27926200

llvm-svn: 280728

fix formatting; NFC

llvm-svn: 280727

[MCTargetDesc] Delete dead code. Found by GCC7 -Wunused-function.

Also unbreak newer gcc build with -Werror.

llvm-svn: 280726

[Release notes] Fix links.

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

llvm-svn: 280725

Add a comment.

llvm-svn: 280724

Fix comment formatting for DebugInfoFlags.def

llvm-svn: 280722

Updated .clang-format rules so bring LLDB in line with LLVM standards.

llvm-svn: 280721

bugpoint: Return Errors instead of passing around strings

This replaces the threading of `std::string &Error` through all of
these APIs with checked Error returns instead. There are very few
places here that actually emit any errors right now, but threading the
APIs through will allow us to replace a bunch of exit(1)'s that are
scattered through this code with proper error handling.

This is more or less NFC, but does move around where a couple of error
messages are printed out.

llvm-svn: 280720

[SE] Remove Platform*Handle classes

Summary:
As pointed out by jprice, these classes don't serve a purpose. Instead,
we stay consistent with the way memory is managed and let the Stream and
Kernel classes directly hold opaque handles to device Stream and Kernel
instances, respectively.

Reviewers: jprice, jlebar

Subscribers: parallel_libs-commits

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

llvm-svn: 280719

Formatting with clang-format patch r280701

llvm-svn: 280718

[RDF] Ignore undef use operands

llvm-svn: 280717

Formatting with clang-format patch r280700

llvm-svn: 280716

[SelectionDAG] Simplify extract_subvector( insert_subvector ( Vec, In, Idx ), Idx ) -> In

If we are extracting a subvector that has just been inserted then we should just use the original inserted subvector.

This has come up in certain several x86 shuffle lowering cases where we are crossing 128-bit lanes.

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

llvm-svn: 280715

Add #include <cstdio> to unbreak build (missing definition of stderr)

llvm-svn: 280714

[JumpThreading] Only write back branch-weight MDs for blocks that originally had PGO info

Currently the pass updates branch weights in the IR if the function has
any PGO info (entry frequency is set).  However we could still have
regions of the CFG that does not have branch weights collected (e.g. a
cold region).  In this case we'd use static estimates.  Since static
estimates for branches are determined independently, they are
inconsistent.  Updating them can "randomly" inflate block frequencies.

I've run into this in a completely cold loop of h264ref from
SPEC.  -Rpass-with-hotness showed the loop to be completely cold during
inlining (before JT) but completely hot during vectorization (after JT).

The new testcase demonstrate the problem.  We check array elements
against 1, 2 and 3 in a loop.  The check against 3 is the loop-exiting
check.  The block names should be self-explanatory.

In this example, jump threading incorrectly updates the weight of the
loop-exiting branch to 0, drastically inflating the frequency of the
loop (in the range of billions).

There is no run-time profile info for edges inside the loop, so branch
probabilities are estimated.  These are the resulting branch and block
frequencies for the loop body:

                check_1 (16)
            (8) /  |
            eq_1   | (8)
                \  |
                check_2 (16)
            (8) /  |
            eq_2   | (8)
                \  |
                check_3 (16)
            (1) /  |
       (loop exit) | (15)
                   |
              (back edge)

First we thread eq_1 -> check_2 to check_3.  Frequencies are updated to
remove the frequency of eq_1 from check_2 and then from the false edge
leaving check_2.  Changed frequencies are highlighted with * *:

                check_1 (16)
            (8) /  |
           eq_1~   | (8)
           /       |
          /     check_2 (*8*)
         /  (8) /  |
         \  eq_2   | (*0*)
          \     \  |
           ` --- check_3 (16)
            (1) /  |
       (loop exit) | (15)
                   |
              (back edge)

Next we thread eq_1 -> check_3 and eq_2 -> check_3 to check_1 as new
back edges.  Frequencies are updated to remove the frequency of eq_1 and
eq_3 from check_3 and then the false edge leaving check_3 (changed
frequencies are highlighted with * *):

                  check_1 (16)
              (8) /  |
             eq_1~   | (8)
             /       |
            /     check_2 (*8*)
           /  (8) /  |
          /-- eq_2~  | (*0*)
  (back edge)        |
                  check_3 (*0*)
            (*0*) /  |
         (loop exit) | (*0*)
                     |
                (back edge)

As a result, the loop exit edge ends up with 0 frequency which in turn makes
the loop header to have maximum frequency.

There are a few potential problems here:

1. The profile data seems odd.  There is a single profile sample of the
loop being entered.  On the other hand, there are no weights inside the
loop.

2. Based on static estimation we shouldn't set edges to "extreme"
values, i.e. extremely likely or unlikely.

3. We shouldn't create profile metadata that is calculated from static
estimation.  I am not sure what policy is but it seems to make sense to
treat profile metadata as something that is known to originate from
profiling.  Estimated probabilities should only be reflected in BPI/BFI.

Any one of these would probably fix the immediate problem.  I went for 3
because I think it's a good policy to have and added a FIXME about 2.

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

llvm-svn: 280713

Fix for Bindings/Go/go.test after patch r280700

llvm-svn: 280711

[Sparc][Leon] Corrected supported atomics size for processors supporting Leon CASA instruction back to 32 bits.

This was erroneously checked-in for 64 bits while trying to find if there was a way to get 64 bit atomicity in Leon processors. There is not and this change should not have been checked-in. There is no unit test for this as the existing unit tests test for behaviour to 32 bits, which was the original intention of the code.

llvm-svn: 280710

Mark R_GOTREL_FROM_END as a relative expression.

Fixes pr30282.

llvm-svn: 280709

[ELF] - Linkerscript: implemented FILL command as alias for =fillexpr

Patch implements FILL just as alias for =fillexpr.
This allows to make implementation much shorted and simpler than D24186.

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

llvm-svn: 280708

Fixing an MSVC error from rL280692

MSVC emits an error when one uses a const variable in a lambda without
capturing it.

gcc and clang don't emit an error in this scenario.

llvm-svn: 280707

[mips] Tighten FastISel restrictions

LLVM PR/29052 highlighted that FastISel for MIPS attempted to lower
arguments assuming that it was using the paired 32bit registers to
perform operations for f64. This mode of operation is not supported
for MIPSR6.

This patch resolves the reported issue by adding additional checks
for unsupported floating point unit configuration.

Thanks to mike.k for reporting this issue!

Reviewers: seanbruno, vkalintiris

Differential Review: https://reviews.llvm.org/D23795

llvm-svn: 280706

[PPC] Claim stack frame before storing into it, if no red zone is present

Unlike PPC64, PPC32/SVRV4 does not have red zone. In the absence of it
there is no guarantee that this part of the stack will not be modified
by any interrupt. To avoid this, make sure to claim the stack frame first
before storing into it.

This fixes https://llvm.org/bugs/show_bug.cgi?id=26519.

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

llvm-svn: 280705

Second round of fixups for r280692

Android targets don't have std::to_string and std::stoul. Use llvm::to_string and strtoul
instead.

llvm-svn: 280704

Revert "Intel(R) Memory Protection Extensions (Intel(R) MPX) support."

This reverts commit rL280668 because the register tests fail on i386
Linux.

I investigated a little bit what causes the failure - there are missing
registers when running 'register read -a'.
This is the output I got at the bottom:
"""
...
Memory Protection Extensions:
      bnd0 = {0x0000000000000000 0x0000000000000000}
      bnd1 = {0x0000000000000000 0x0000000000000000}
      bnd2 = {0x0000000000000000 0x0000000000000000}
      bnd3 = {0x0000000000000000 0x0000000000000000}

unknown:
2 registers were unavailable.
"""

Also looking at the packets exchanged between the client and server:
"""
...
history[308] tid=0x7338 <  19> send packet: $qRegisterInfo4a#d7
history[309] tid=0x7338 < 130> read packet:
$name:bnd0;bitsize:128;offset:1032;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:101;dwarf:101;#48
history[310] tid=0x7338 <  19> send packet: $qRegisterInfo4b#d8
history[311] tid=0x7338 < 130> read packet:
$name:bnd1;bitsize:128;offset:1048;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:102;dwarf:102;#52
history[312] tid=0x7338 <  19> send packet: $qRegisterInfo4c#d9
history[313] tid=0x7338 < 130> read packet:
$name:bnd2;bitsize:128;offset:1064;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:103;dwarf:103;#53
history[314] tid=0x7338 <  19> send packet: $qRegisterInfo4d#da
history[315] tid=0x7338 < 130> read packet:
$name:bnd3;bitsize:128;offset:1080;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:104;dwarf:104;#54
history[316] tid=0x7338 <  19> send packet: $qRegisterInfo4e#db
history[317] tid=0x7338 <  76> read packet:
$name:bndcfgu;bitsize:64;offset:1096;encoding:vector;format:vector-uint8;#99
history[318] tid=0x7338 <  19> send packet: $qRegisterInfo4f#dc
history[319] tid=0x7338 <  78> read packet:
$name:bndstatus;bitsize:64;offset:1104;encoding:vector;format:vector-uint8;#8e
...
"""

The bndcfgu and bndstatus registers don't have the 'Memory Protections
Extension' set. I looked at the code and it seems that that is set
correctly.

So I'm not sure what's the problem or where does it come from.

Also there is a second failure related to something like this in the
tests:
"""
registerSet.GetName().lower()
"""

For some reason the registerSet.GetName() returns None.

llvm-svn: 280703

[clang-cl] Check that we are in clang cl mode before enabling support for the CL environment variable.

Checking for the type of the command line tokenizer should not be the criteria to enable support for the CL environment variable, this change checks that we are in clang-cl mode instead.

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

llvm-svn: 280702