Summary:
-simplifycfg is the legacy pass name for SimplifyCFGPass.

There is already -simplify-cfg in FUNCTION_PASS_WITH_PARAMS which
handles options for SimplifyCFGPass. Maybe that should be renamed to
-simplifycfg as well?

This reduces the number of check-llvm failures under NewPM from 2619 to 2392.

Reviewers: hans, leonardchan, asbirlea, ychen

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Summary:
This implementation uses a pre-trained model which is statically
compiled into a native function.

RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140763.html

Reviewers: davidxl, jdoerfert, dblaikie

Subscribers: mgorny, eraman, hiraditya, arphaman, llvm-commits

Tags: #llvm

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

Summary:
Currently, add_llvm_library would create an OBJECT library alongside
of a STATIC / SHARED library, but losing the link interface (its
elements would become dependencies instead). To support scenarios
where linking an object library also brings in its usage
requirements, this patch adds support for 'stand-alone' OBJECT
libraries - i.e. without an accompanying SHARED/STATIC library, and
maintaining the link interface defined by the user.

This is useful for cases where, for example, we want to build a part
of a component separately. Using a STATIC target would incur the risk
that symbols not referenced in the consumer would be dropped (which may
be undesirable).

The current application is the ML part of Analysis. It should be part
of the Analysis component, so it may reference other analyses; and (in
upcoming changes) it has dependencies on optional libraries.

Reviewers: karies, davidxl, beanz, phosek, smeenai

Subscribers: mgorny, hiraditya, llvm-commits

Tags: #llvm

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

Soon it will be disallowed to depend on MachineFunction state in the
constructor. This was only being used to get the MachineRegisterInfo
for an assert, which I'm not sure is necessarily worth it. I would
think any missing defs would be caught by the verifier later instead.

Fix implicit include dependencies in source files.

Summary: We are missing the error-bit somehow if the error-bit is propagated
through the code path: "error type/expr" -> "template argument" ->
"template specialization type", which will lead to crashes.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

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

The "type" argument to the function is mostly useless -- the only
interesting aspect of it is signedness. Pass signedness directly and
compute the value of bits and signedness fields -- that's exactly
what the single caller of this function does.

Summary:
The SIModeRegister pass attempts to generate the minimal number of
writes to the mode register. However it was failing to correctly
deal with some loops, resulting in some redundant setreg instructions
being inserted.

This change amends the pass to avoid generating these redundant
instructions.

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits

Tags: #llvm

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

Start using the `checkGNUHashTable` helper which was recently introduced to report
a proper warning when a GNU hash table goes past the end of the file.

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

Fix implicit include dependencies in source files.

Add support for the 34bit relocation R_PPC64_GOT_PCREL34 for
PC Relative in LLD.

Reviewers: sfertile, MaskRay

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

This patch add support for eliminating MemoryDefs that do not have any
aliasing users, which indicates that there are no reads/writes to the
memory location until the end of the function.

To eliminate such defs, we have to ensure that the underlying object is
not visible in the caller and does not escape via returning. We need a
separate check for that, as InvisibleToCaller does not consider returns.

Reviewers: dmgreen, rnk, efriedma, bryant, asbirlea, Tyker, george.burgess.iv

Reviewed By: asbirlea

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

Summary:
This defines some basic information about ICVs in `OMPKinds.def`.
We also emit remarks with initial values for each function (which are default for now)
as a way to test this.

Reviewers: jdoerfert, JonChesterfield, hamax97, jhuber6

Subscribers: yaxunl, hiraditya, guansong, llvm-commits

Tags: #llvm

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

Add implicit InstIterator.h dependency in ObjCARCContract.cpp

I have been trying to reduce the installed size of our CHERI toolchain and
noticed that this tool was being installed even with -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON.
This appears to be a test binary that should not be installed.

Reviewed By: v.g.vassilev
Differential Revision: https://reviews.llvm.org/D82169

Summary:
After D50078, we're experiencing unexpected un-indent using a style combining `AlignOperands: DontAlign` with `BreakBeforeTernaryOperators: false`, such as Google's JavaScript style:
```
% bin/clang-format -style=google ~/test.js
aaaaaaaaaaa = bbbbbbbb ? cccccccccccccccccc() :
dddddddddd             ? eeeeeeeeeeeeee :
                         fffff;
```
The issue lies with the interaction of `AlignOperands: DontAlign` and the edited code section in ContinuationIndenter.cpp, which de-dents the intent by `Style.ContinuationIndentWidth`. From [[ https://github.com/llvm/llvm-project/blob/ac3e5c4d93fbe7fb2db3c745c721aff41cc1b851/clang/include/clang/Format/Format.h#L170 | the documentation ]] of AlignOperands: DontAlign:
> The wrapped lines are indented `ContinuationIndentWidth` spaces from the start of the line.
So the de-dent effectively erases the necessary `ContinuationIndentWidth` in that case.

This patch restores the `AlignOperands: DontAlign` behavior, producing:
```
% bin/clang-format -style=google ~/test.js
aaaaaaaaaaa = bbbbbbbb ? cccccccccccccccccc() :
    dddddddddd         ? eeeeeeeeeeeeee :
                         fffff;
```

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

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

Currently we crash when trying to print --sections and the SHN_XINDEX escape value
is used for the e_shstrndx field, but there is no section header at index 0 to
read the value from.

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

Let this function (try to) evaluate expressions, in addition to
declarations and compound statements.

Patch by Christian Kandeler <christian.kandeler@qt.io>

Reviewers: nik, akyrtzi, arphaman, jkorous

Reviewed By: jkorous

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

Reviewed By: fpetrogalli

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

Reviewed By: fpetrogalli

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

Summary:
Added for following intrinsics:

  * zip1, zip2, zip1q, zip2q
  * trn1, trn2, trn1q, trn2q
  * uzp1, uzp2, uzp1q, uzp2q
  * splice
  * rev
  * sel

Reviewed By: david-arm

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

Summary:
Bfloat16 support added for the following intrinsics:
 - LD1
 - LD1RQ
 - LDNT1
 - LDNF1
 - LDFF1

Reviewers: sdesmalen, c-rhodes, efriedma, stuij, fpetrogalli, david-arm

Reviewed By: fpetrogalli

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, danielkiss, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

Summary:
Whenever Neon is not supported, a generic message is printed:

  error: "NEON support not enabled"

Followed by a series of other error messages that are not useful once
the first one is printed.

This patch gives a more precise message in the case where Neon is
unsupported because an invalid float ABI was specified: the soft float
ABI.

  error: "NEON intrinsics not available with the soft-float ABI. Please
  use -mfloat-abi=softfp or -mfloat-abi=hard"

This message is the same one that GCC gives, so it is also making their
diagnostics more compatible with each other.

Also, by rearranging preprocessor directives, these "unsupported" error
messages are now the only ones printed out, which is also GCC's
behaviour.

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

Summary: Details: This patch enables SETCC to be selected to S_CMP_* if uniform and V_CMP_* if divergent.

Reviewers: rampitec, arsenm

Reviewed By: rampitec

Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits

Tags: #llvm

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

Summary:
This change permits scalar bfloats to be loaded, stored, moved and
used as function call arguments and return values, whenever the bf16
feature is supported by the subtarget.

Previously that was only supported in the presence of the fullfp16
feature, because the code generation strategy depended on instructions
from that extension. This change adds alternative code generation
strategies so that those operations can be done even without fullfp16.

The strategy for loads and stores is to replace VLDRH/VSTRH with
integer LDRH/STRH plus a move between register classes. I've written
isel patterns for those, conditional on //not// having the fullfp16
feature (so that in the fullfp16 case, the existing patterns will
still be used).

For function arguments and returns, instead of writing isel patterns
to match `VMOVhr` and `VMOVrh`, I've avoided generating those SDNodes
in the first place, by factoring out the code that constructs them
into helper functions `MoveToHPR` and `MoveFromHPR` which have a
fallback for non-fullfp16 subtargets.

The current output code is not especially pretty: in the new test file
you can see unnecessary store/load pairs implementing no-op bitcasts,
and lots of pointless moves back and forth between FP registers and
GPRs. But it at least works, which is an improvement on the previous
situation.

Reviewers: dmgreen, SjoerdMeijer, stuij, chill, miyuki, labrinea

Reviewed By: dmgreen, labrinea

Subscribers: labrinea, kristof.beyls, hiraditya, danielkiss, llvm-commits

Tags: #llvm

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

Summary: Looks like this is a fallout when we introduce the error-bit in Type.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

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

Summary:
otherwise we'll run into code path which expects a good base specifiers,
and lead to crashes.

The crash only occurs in template instantiations (in non-template case,
the bad base specifiers are dropped during parsing.)

crash stacktrace:

```
clang: llvm-project/clang/lib/Sema/SemaInit.cpp:7864: clang::ExprResult clang::InitializationSequence::Perform(clang::Sema &, const clang::InitializedEntity &, const clang::InitializationKind &, clang::MultiExprArg, clang::QualType *): Assertion `Kind.getKind() == InitializationKind::IK_Copy || Kind.isExplicitCast() || Kind.getKind() == InitializationKind::IK_DirectList' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
```

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

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

Summary:
This patch enables compilation of C code for the VE target with Clang.

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

[X86] Speculatively fix to X86AvoidStoreForwardingBlocks not deference a machine mem operand if there isn't one present.

Eric Christopher informed me that FastISel memcpy handling creates
load/store instructions without mem operands. We should fix that,
but I doubt that's the only case of missed mem operands so seems
better to be defensive here.

I don't have a test case yet, but I'll try to add one if i get a
test from Eric.

Specifically: copysignl, frexpl, logbl and modfl have been added.

Reviewers: asteinhauser

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