This allows running Lit tests that run ssh without having to manually
enter a password (which is inconvenient), by just having ssh-agent
setup properly when running the test suite.

Reviewers: arsenm

Subscribers: sdardis, wdng, hiraditya, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, ecnelises, llvm-commits

Tags: #llvm

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

declaration is not visible.

In passing, add a test for a similar case of conflicting redeclarations
of internal-linkage structured bindings. (This case already works).

G++ 10.1 emits inappropriate "use of uninitialized data" warnings when
compiling f18.  The warnings stem from two sites in templatized code
whose multiple instantiations magnified the number of warnings.

These changes dodge those warnings by making some innocuous changes to
the code.  In the parser, the idiom defaulted(cut >> x), which yields a
parser that always succeeds, has been replaced with a new equivalent
pass<T>() parser that returns a default-constructed value T{} in an
arguably more readable fashion.  This idiom was the only attestation of
the basic parser cut, so it has been removed and the remaining code
simplified.  In Evaluate/traverse.h, a return {}; was replaced with a
return of a default-constructed member.

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

We select all of these via patterns now, so there's no reason to disallow this.

Update select-dup.mir to show that we correctly select the smaller types.

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

This was making it so that the instructions weren't eliminated in
select-rev.mir and select-trn.mir despite not being used.

Update the tests accordingly.

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

Prior to my patch of using the LLVM line table parsing code,
SymbolFileDWARF::ParseSupportFiles would only parse the line table
prologues to get the file list for any files that could be in the line
table.

With the old behavior, if we found the file that someone is setting the
breakpoint in in the support files list, we would get a valid index. If
we didn't, we would not look any further. So someone sets a breakpoint
one "MyFile.cpp:12" and if we find "MyFile.cpp" in the support file list
for the compile unit, then and only then would we get the entire line
table for that compile unit.

With the current behavior, no matter what, we always fully parse the
line table for all compile units any time any file and line breakpoint
is set. This creates a serious problem when debugging a large DWARF in
.o file project.

This patch re-instates the old behavior. Unfortunately it means we might
end up parsing to prologue twice, but I don't think that outweighs the
cost of trying to cache/reuse it.

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

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

We were using llvm::SmallPtrSet for our ODR-use set which was also used
for instantiating the implicit lambda captures. The order in which the
captures are added depends on this, so the lambda's layout ended up
changing.  The test just uses floats, but this was noticed with other
types as well.

This test replaces the short-lived SmallPtrSet (it lasts only for an
expression, which, though is a long time for lambdas, is at least not
forever) with a SmallSetVector.

Instead of parsing the command each time prior to calling _executeScriptInternal,
do it once inside _executeScriptInternal.

llvm/lib/Target/AArch64/AArch64SLSHardening.cpp:146:5: warning: suggest braces around initialization of subobject [-Wmissing-braces]
    "__llvm_slsblr_thunk_x0",  "__llvm_slsblr_thunk_x1",
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    {
llvm/lib/Target/AArch64/AArch64SLSHardening.cpp:168:5: warning: suggest braces around initialization of subobject [-Wmissing-braces]
    AArch64::X0,  AArch64::X1,  AArch64::X2,  AArch64::X3,  AArch64::X4,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    {

That test is already only enabled if LIBCXX_TEST_GDB_PRETTY_PRINTERS is
enabled, which isn't the default. If someone turns on that option on
Windows, they should be able to run the test and see whatever failure
happens.

Summary:
Add Adaptor alias alongside OperandAdaptor to make next renaming more
mechanical. OperandAdaptor's are no longer just about operands.
Considered OpAdaptor too, but then noticed we'd mostly end up with
XOp::OpAdaptor which seems redundant.

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

This allows running the scripts directly, without running them through
Python.

This was originally 658af943 and reverted in 665dbe91.
The clang bug this triggered was fixed in 05ed3efc.

Summary:
DelayedTemplateParsing is marked as BENIGN_LANGOPT, so we are allowed to
use a delayed template in a non-delayed TU.
(This is clangd's default configuration on windows: delayed-template-parsing
is on for the preamble and forced off for the current file)

However today clang fails to parse implicit instantiations in a non-dtp
TU of templates defined in a dtp PCH file (and presumably module?).
In this case the delayed parser is not registered, so the function is
simply marked "delayed" again. We then hit an assert:
end of TU template instantiation should not create more late-parsed templates

Reviewers: rsmith

Subscribers: ilya-biryukov, usaxena95, cfe-commits, kadircet

Tags: #clang

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

Summary:
Fix several typos in Toy tutorial chapters.
- Chapter 2
- Chapter 5

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

DAGCombiner optimization for pow(x,0.75) and pow(x,0.25) on double and single precision even in case massv function is asked

Here, I am proposing to add an special case for massv powf4/powd2 function (SIMD counterpart of powf/pow function in MASSV library) in MASSV pass to get later optimizations like conversion from pow(x,0.75) and pow(x,0.25) for double and single precision to sequence of sqrt's in the DAGCombiner in vector float case. My reason for doing this is: the optimized pow(x,0.75) and pow(x,0.25) for double and single precision to sequence of sqrt's is faster than powf4/powd2 on P8 and P9.

In case MASSV functions is called, and if the exponent of pow is 0.75 or 0.25, we will get the sequence of sqrt's and if exponent is not 0.75 or 0.25 we will get the appropriate MASSV function.

Reviewed By: steven.zhang

Tags: #LLVM #PowerPC

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

These ops have the same operands and result shapes.

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

In TestRunner.py, D78589 extracts a `_parseKeywords` function from
`parseIntegratedTestScript`, which then expects `_parseKeywords` to
always return a list of keyword/value pairs.  However, the extracted
code sometimes returns an unresolved `lit.Test.Result` on a keyword
parsing error, which then produces a stack dump instead of the
expected diagnostic.

This patch fixes that, makes the style of those diagnostics more
consistent, and extends the lit test suite to cover them.

Reviewed By: ldionne

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

Refactor redzone size calculation. This will simplify changing the
redzone size calculation in future.

Note that AddressSanitizer.cpp violates the latest LLVM style guide in
various ways due to capitalized function names. Only code related to the
change here was changed to adhere to the style guide.

No functional change intended.

Reviewed By: andreyknvl

Tags: #llvm

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

Reland https://reviews.llvm.org/D76696
All known crashes have been fixed, another attemption.

We have rolled out this to all internal users for a while, didn't see
big issues, we consider it is stable enough.

Reviewed By: sammccall

Subscribers: rsmith, hubert.reinterpretcast, ebevhan, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

The thrilling conclusion to the barrage of patches I uploaded lately! This is a
big milestone towards the goal set out in http://lists.llvm.org/pipermail/cfe-dev/2019-August/063070.html.
I hope to accompany this with a patch where the a coreModeling package is added,
from which package diagnostics aren't allowed either, is an implicit dependency
of all checkers, and the core package for the first time can be safely disabled.

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

As reported in PR46111, implicit instantiation of a deduction guide
causes us to have an elaborated type as the parameter, rather than the
dependent type.

After review and feedback from @rsmith, this patch solves this problem
by wrapping the value in an uninstantiated typedef/type-alias that is
instantiated when required later.

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

Checker dependencies were added D54438 to solve a bug where the checker names
were incorrectly registered, for example, InnerPointerChecker would incorrectly
emit diagnostics under the name MallocChecker, or vice versa [1]. Since the
system over the course of about a year matured, our expectations of what a role
of a dependency and a dependent checker should be crystallized a bit more --
D77474 and its summary, as well as a variety of patches in the stack
demonstrates how we try to keep dependencies to play a purely modeling role. In
fact, D78126 outright forbids diagnostics under a dependency checkers name.

These dependencies ensured the registration order and enabling only when all
dependencies are satisfied. This was a very "strong" contract however, that
doesn't fit the dependency added in D79420. As its summary suggests, this
relation is directly in between diagnostics, not modeling -- we'd prefer a more
specific warning over a general one.

To support this, I added a new dependency kind, weak dependencies. These are not
as strict of a contract, they only express a preference in registration order.
If a weak dependency isn't satisfied, the checker may still be enabled, but if
it is, checker registration, and transitively, checker callback evaluation order
is ensured.

If you are not familiar with the TableGen changes, a rather short description
can be found in the summary of D75360. A lengthier one is in D58065.

[1] https://www.youtube.com/watch?v=eqKeqHRAhQM

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

Noticed while trying to cleanup D66004 - if a shuffle operand came from a scalar, we're better off using INSERTPS vs UNPCKLPS as this is more likely to load fold later on. It also matches our existing BUILD_VECTOR lowering.

We can extend this to other PINSRB/D/Q/W cases in the future as the need arises.

Add `NoSideEffect` trait to `shape.to_extent_tensor` and
`shape.from_extent_tensor` and defined custom assembly format for the
operations.

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

This patch adds a new option to CriticalEdgeSplittingOptions to control
whether loop-simplify form must be preserved. It is them used by GVN to
indicate that loop-simplify form does not have to be preserved.

This fixes a crash exposed by 189efe29.

If the critical edge we are splitting goes from a block inside a loop to
a block outside the loop, splitting the edge will create a new exit
block. As a result, the new block will branch to the original exit
block, which will add a non-loop predecessor, breaking loop-simplify
form. To preserve loop-simplify form, the predecessor blocks of the
original exit are split, but that does not work for blocks with
indirectbr terminators. If preserving loop-simplify form is requested,
bail out , before making any changes.

Reviewers: reames, hfinkel, davide, efriedma

Reviewed By: efriedma

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

Exactly what it says on the tin! "Strong" dependencies are mentioned in contrast
to a new kind of dependency introduced in a followup patch.

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

This patch addresses comments in [D81450](https://reviews.llvm.org/D81450#inline-748745)

Reviewed By: jhenderson

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

[CodeGen] Increase applicability of ffine-grained-bitfield-accesses for targets with limited native integer widths

As pointed out in PR45708, -ffine-grained-bitfield-accesses doesn't
trigger in all cases you think it might for RISC-V. The logic in
CGRecordLowering::accumulateBitFields checks OffsetInRecord is a legal
integer according to the datalayout. RISC targets will typically only
have the native width as a legal integer type so this check will fail
for OffsetInRecord of 8 or 16 when you would expect the transformation
is still worthwhile.

This patch changes the logic to check for an OffsetInRecord of a at
least 1 byte, that fits in a legal integer, and is a power of 2. We
would prefer to query whether native load/store operations are
available, but I don't believe that is possible.

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