[mlir][AsmPrinter] Refactor printing to only print aliases for attributes/types that will exist in the output.

This revision refactors the way that attributes/types are considered when generating aliases. Instead of considering all of the attributes/types of every operation, we perform a "fake" print step that prints the operations using a dummy printer to collect the attributes and types that would actually be printed during the real process. This removes a lot of attributes/types from consideration that generally won't end up in the final output, e.g. affine map attributes in an `affine.apply`/`affine.for`.

This resolves a long standing TODO w.r.t aliases, and helps to have a much cleaner textual output format. As a datapoint to the latter, as part of this change several tests were identified as testing for the presence of attributes aliases that weren't actually referenced by the custom form of any operation.

To ensure that this wouldn't cause a large degradation in compile time due to the second full print, I benchmarked this change on a very large module with a lot of operations(The file is ~673M/~4.7 million lines long). This file before this change take ~6.9 seconds to print in the custom form, and ~7 seconds after this change. In the custom assembly case, this added an average of a little over ~100 miliseconds to the compile time. This increase was due to the way that argument attributes on functions are structured and how they get printed; i.e. with a better representation the negative impact here can be greatly decreased. When printing in the generic form, this revision had no observable impact on the compile time. This benchmarking leads me to believe that the impact of this change on compile time w.r.t printing is closely related to `print` methods that perform a lot of additional/complex processing outside of the OpAsmPrinter.

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

Our range computation methods benefit from no-wrap flags. But if the ranges
were first computed before the flags were set, the cached range will be too
pessimistic.

We need to drop cached ranges whenever we sharpen AddRec's no wrap flags.

Differential Revision: https://reviews.llvm.org/D89847
Reviewed By: fhahn

Excluded folders in scan build is turned to absolute path before
comapre to 'file' in cdb. 'file' in cdb might be a path relative
to 'directory', so we need to turn it to absolute path before
comparison.

Patch by Yu Shan

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

If the source of S_MOV_{B32,B64}_term is an immediate then it
cannot be lowered to a COPY.

Reviewed By: arsenm

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

This patch adds three intrinsics compatible to x86's SSE 4.1 on PowerPC
target, with tests:

- _mm_insert_epi8
- _mm_insert_epi32
- _mm_insert_epi64

The intrinsics implementation is contributed by Paul Clarke.

Reviewed By: jsji

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

Reviewed By: asbirlea

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

For consistency with the IRBuilder, OpenMPIRBuilder has method names starting with 'Create'. However, the LLVM coding style has methods names starting with lower case letters, as all other OpenMPIRBuilder already methods do. The clang-tidy configuration used by Phabricator also warns about the naming violation, adding noise to the reviews.

This patch renames all `OpenMPIRBuilder::CreateXYZ` methods to `OpenMPIRBuilder::createXYZ`, and updates all in-tree callers.

I tested check-llvm, check-clang, check-mlir and check-flang to ensure that I did not miss a caller.

Reviewed By: mehdi_amini, fghanim

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

This patch simplifies BranchProbabilityInfo by changing the type of
Probs.

Without this patch:

  DenseMap<Edge, BranchProbability> Probs

maps an ordered pair of a BasicBlock* and a successor index to an edge
probability.

With this patch:

  DenseMap<const BasicBlock *, SmallVector<BranchProbability, 2>> Probs

maps a BasicBlock* to a vector of edge probabilities.

BranchProbabilityInfo has a property that for a given basic block, we
either have edge probabilities for all successors or do not have any
edge probability at all.  This property combined with the current map
type leads to a somewhat complicated algorithm in eraseBlock to erase
map entries one by one while increasing the successor index.

The new map type allows us to remove the all edge probabilities for a
given basic block in a more intuitive manner, namely:

  Probs.erase(BB);

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

Prior to D89768, any alloca that's used after suspension points will be put on to the coroutine frame, and hence they will always be reloaded in the resume function.
However D89768 introduced a more precise way to determine whether an alloca should live on the frame. Allocas that are only used within one suspension region (hence does not need to live across suspension points) will not be put on the frame. They will remain local to the resume function.
When creating the new entry for the .resume function, the existing logic only moved all the allocas from the old entry to the new entry. This covers every alloca from the old entry. However allocas that's defined afer coro.begin are put into a separate basic block during CoroSplit (the PostSpill basic block). We need to make sure these allocas are moved to the new entry as well if they are used.
This patch walks through all allocas, and check if they are still used but are not reachable from the new entry, if so, we move them to the new entry.

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

This fixes a reproducer test failure that was caused by the undefined
order in which global destructors run. More concretely, the static
instance of the RealFileSystem had been destroyed before we finalized
the reproducer, which uses it to copy files into the reproducer. By
exiting normally, we call SBDebugger::Terminate and finalize the
reproducer before any static dtors are run.

Emscripten doesn't use this file (at least not anymore), it uses
exception_libcxxabi.ipp since _LIBCPPABI_VERSION is defined.

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

This instruments a should-run-optional-pass callback using the existing
OptBisect class to decide if new passes should be skipped. Passes that
force isRequired never reach this at all, so they are not included in
"BISECT:" output nor its pass count.

The test case is resurrected from r267022, an early version of D19172
that had new pass manager support (later reverted and redone without).

Reviewed By: aeubanks

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

Reviewed By: rnk

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

Return references from GetDummyTarget and GetSelectedOrDummyTarget. This
matches how the APIs are already used in practice.

This allows us to omit one level of indirection when querying
the information from the underlying attribute.

Reviewed By: hanchung, ThomasRaoux

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

This ports a number of OpenCL and fast-math flags for floating point
over to the new marshalling infrastructure.

As part of this, `Opt{In,Out}FFlag` were enhanced to allow other flags to
imply them, via `DefaultAnyOf<>`. For example:
```
defm signed_zeros : OptOutFFlag<"signed-zeros", ...,
  "LangOpts->NoSignedZero",
  DefaultAnyOf<[cl_no_signed_zeros, menable_unsafe_fp_math]>>;
```
defines `-fsigned-zeros` (`false`) and `-fno-signed-zeros` (`true`)
linked to the keypath `LangOpts->NoSignedZero`, defaulting to `false`,
but set to `true` implicitly if one of `-cl-no-signed-zeros` or
`-menable-unsafe-fp-math` is on.

Note that the initial patch was written Daniel Grumberg.

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

This reverts commit 55120f74.

Segfaults during build:
http://lab.llvm.org:8011/#/builders/36/builds/1310

So far, only used to generate Kind and implement classof().

My plan is to have this general-purpose Nodes.inc in the style of AST
DeclNodes.inc etc, and additionally a special-purpose backend generating
the actual class definitions. But baby steps...

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

This reverts commit 4d81c8ad.

Apparently, we have code that indirectly uses #pragma
execution_character_set which depends on utf-8 not being set:

http://lab.llvm.org:8011/#/builders/127/builds/1161/steps/4/logs/stdio

- Add shorter helper functions to set visibility for Symbols.

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

When building the runtimes, it's very important not to add rpaths unless
the user explicitly asks for them (the standard way being CMAKE_INSTALL_RPATH),
or to change the install name dir unless the user requests it (via
CMAKE_INSTALL_NAME_DIR).

llvm_setup_rpath() would override the install_name_dir of the runtimes
even if CMAKE_INSTALL_NAME_DIR was specified to something, which is wrong
and in fact even "dangerous" for the runtimes.

This issue was discovered when trying to build libc++ and libc++abi as
system libraries for Apple, where we set the install name dir to /usr/lib
explicitly. llvm_setup_rpath() would cause libc++ to have the wrong install
name dir, and for basically everything on the system to fail to load.
This was discovered just now because we previously used something closer
to a standalone build, where llvm_setup_rpath() wouldn't exist, and hence
not be used.

This is a revert of the following commits:

  libunwind: 3a667b9b
  libc++abi: 4877063e
  libc++: 88434fe0

Those added llvm_setup_rpath() for consistency, so it seems reasonable
to revert.

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

Follow-up on https://reviews.llvm.org/D88553#inline-837013

Reviewed By: sammccall

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

Symptoms: https://github.com/clangd/clangd/issues/571

Reviewed By: kadircet

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

Modern Fortran compilers support Fortran 90, so we do not need to use
the source code for Fortran compilers that do not support Fortran 90.

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

This breaks a cyclic dependency. clangDeamon doesn't need to depend on
clangdRemoteIndex yet.

Fix DS/ES/FS/GS register sizes in getter/setter for NetBSD.  Apparently
only CS and SS registers are specified as 64/32-bit in LLDB, while
the others are specified as 16-bit.

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

CreateCanonicalLoop generates a standardized control flow structure for OpenMP canonical for loops. The structure can be consumed by loop-associated directives such as worksharing-loop, distribute, simd etc. as well as loop transformations such as tile and unroll.

This is a first design without considering all complexities yet. The control-flow emits more basic block than strictly necessary, but these will be optimized by CFGSimplify anyway, provide a nice separation of concerns and might later be useful with more complex scenarios. I successfully implemented a basic tile construct using this API, which is not part of this patch.

The fundamental building block is the CreateCanonicalLoop that only takes the loop trip count and operates on the logical iteration spaces only. An overloaded CreateCanonicalLoop for using LB, UB, Increment is provided as well, but at least for C++, Clang will need to implement a loop counter to logical induction variable mapping anyway, since iterator overload resolution cannot be done in LLVMFrontend.

As there currently is no user for CreateCanonicalLoop, it is only called from unittests. Similarly, CanonicalLoopInfo::eraseFromParent() is used in my file implementation and might be generally useful for implementing loop-associated constructs, but is not used in this patch itself.

The following non-exhaustive list describes not yet covered items:
 * collapse clause (including non-rectangular and non-perfectly nested); idea is to provide a OpenMPIRBuilder::collapseLoopNest method consuming multiple nested loops and returning a new CanonicalLoopInfo that can be used for loop-associated directives.
 * simarly: ordered clause for DOACROSS loops
 * branch weights
 * Cancellation point (?)
 * AllocaIP
 * break statement (if needed at all)
 * Exceptions (if not completely handled in the front-end)
  * Using it in Clang; this requires implementing at least one loop-associated construct.
 * ...

Reviewed By: jdoerfert

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

The pass combines patterns of ExpandAtomic, ExpandMemRefReshape,
StdExpandDivs passes. The pass is meant to legalize STD for conversion to LLVM.

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

Pass was already ported, just not properly hooked up.

This tests legacy PM specific code (https://bugs.llvm.org/show_bug.cgi?id=37334).
This is failing under the new PM because -loop-sink is a function pass,
not a loop pass, and doesn't run -loop-simplify.

Follows through on c4cb3b10's FIXME
dating back to 2015. Anyone using this should migrate to
InMemoryFileSystem and/or ClangTool::mapVirtualFile.

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

It is not used in the optimization pipeline and can be ported later.

Test behavior before/at/after the GEP decomposition limit.

Extend the existing basic block sections debug info test to check for the correctness of the generated line table.

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

if config.target_triple contains 'windows-msvc', %llc_dwarf has a -mtriple:

    llc.exe: for the --mtriple option: may only occur zero or one times!