breaks amdgpu buildbot

This reverts commit 0f2f3784.

-cfg-dump and -cfg-view were removed long ago. The rest are gone, but
I'm opting not to remove these lines without finding a replacement.

This builtin will be converted to llvm.set.rounding intrinsic
in IR level and should be work with "#pragma STDC FENV_ACCESS ON"
since it changes default FP environment. Users can change rounding
mode via this builtin without introducing libc dependency.

Reviewed by: andrew.w.kaylor, rjmccall, sepavloff
Differential Revision: https://reviews.llvm.org/D144454


Signed-off-by: jinge90 <ge.jin@intel.com>

/data/jiefu/llvm-project/mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensorType.h:63:21: error: definition of implicit copy constructor for 'SparseTensorType' is deprecated because it has a user-declared copy assignment operator [-Werror,-Wdeprecated-copy]
  SparseTensorType &operator=(const SparseTensorType &) = delete;
                    ^
/data/jiefu/llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorStorageLayout.h:239:9: note: in implicit copy constructor for 'mlir::sparse_tensor::SparseTensorType' first required here
      : rType(stt), fields(fields) {
        ^
1 error generated.

Follow Alex Langford's feedback to my patch from
https://reviews.llvm.org/D145547 , and fix a
side issue I noticed while testing this, where
binaries loaded via LC_NOTE metadata were loaded
in the Target twice unnecessarily.

This is to fix run time problem when use:

int **a;
map((*a)[:3]), (*a)[1] or map(**a).

current we skip generate map info for dereference pointer:
&(*a), &(*a)[0], 3*sizeof(int), TARGET_PARAM | TO | FROM

One way to fix runtime problem is to generate map info for dereference
pointer.

map((*a)[:3]):
&(*a), &(*a), sizeof(pointer),  TARGET_PARAM | TO | FROM
&(*a), &(*a)[0], 3*sizeof(int),  PTR_AND_OBJ | TO | FROM

map(**a):
&(*a), &(*a), sizeof(pointer),  TARGET_PARAM | TO | FROM
&(*a), &(**a), sizeof(int),  PTR_AND_OBJ | TO | FROM

The change in CGOpenMPRuntime.cpp add that.

The change in SemaOpenMP is to fix variable of dereference pointer to array
captured by reference.  That is wrong. That cause run time to fail.

The rule is:
If variable is identified in a map clause it is always captured by
reference except if it is a pointer that is dereferenced somehow.

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

We have some non-kexts in the binary list in the Darwin kernel
in some situations.  The binary has likely already been loaded;
check if it has been, and don't re-load it.  Also, if we do need
to load it at this point, if in-memory segment vmaddrs have not
been updated to the actual load addresses, calculate a fixed slide
for the in-memory image and apply that slide to the ondisk binary.

Differential Revision: https://reviews.llvm.org/D145547
rdar://106343477

Depends On D145611

Reviewed By: aartbik

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

Fix logic for repeat commands, so that regex commands (specificially `bt`) are
given the opportunity to provide a repeat command.

rdar://104562616

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

This reverts commit ef122753.

Apparently it is causing some crashes:
https://reviews.llvm.org/D142916#4178869

Polly-ACC is unmaintained and since it has never been ported to the NPM pipeline, since D136621 it is not even accessible anymore without manually specifying the passes on the `opt` command line.

Since there is no plan to put it to a maintainable state, remove it from Polly.

Reviewed By: grosser

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

This helps to reduce the confusion from using `unsigned` everywhere.

Depends On D145606

Reviewed By: Peiming

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

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

The copy assignment is already implicitly deleted, but making it explicit helps clean up compilation error messages.

Reviewed By: Peiming

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

Reviewed By: vitalybuka

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

Shuffle the regions' base address so that the layout of all regions is
less predictable.

Reviewed By: cferris, cryptoad

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

The linker-flags.f90 test checks for the linker command line. The `-target` indicates cross-compiling, the toolchain executables themselves are still running on the native platform. If it is Windows, the driver will try to fully resolve the path to `ld` which may include an `.exe` suffix.

In my case, it resolves to the MinGW installation (`"C:\\tools\\msys64\\usr\\bin\\ld.exe"`) found in `PATH`. The GNU ld that comes with the MSYS2 distribution does not support `elf64lppc` or MacOS emulation modes (`acosx_version_min`), but the test also does not require executing the linker.

Reviewed By: awarzynski

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

Decompose conv_2d -> conv_1d.

This MR follows a similar approach to https://reviews.llvm.org/D112928.

This patch adds support to convert conv_2D operation with either unit height or unit width to conv_1D operation.

This is useful when 2D convolution is tiled to have a single dimension for either height or width and then can be vectorized once it is decomposed into 1D convolution.

This patch https://reviews.llvm.org/D145160 adds vector support for linalg.conv_1d operation and thereby allowing us to vectorize linalg.conv_2d operation after proper tiling.

This missing feature is reported here: https://discourse.llvm.org/t/vectorization-of-convolution-op/60458.

Reviewed By: hanchung

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

This MR add vectorization support for linalg.conv_1D operation.

Reviewed By: nicolasvasilache, hanchung, dcaballe, vmurali

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

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

Makes it harder to write an inexact constant that gets parsed as
a valid constant.

This is max acceptable value with pow of 2 for DefaultSizeClassMap, the
same as for ASAN.

Reviewed By: kstoimenov

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

This turns an idempotent atomic operation into an atomic load.

Fixes: SWDEV-385135

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

This patch adds support for 'm', 'Q', and 'U' memory constraints.

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

In order to support inline asm with memory constraints,
AsmPrinter::PrintAsmMemOperand needs to be implemented, which has lots
of overlaps with MCInstPrinter especially on the format of complex
addressing modes. This patch factors out the common printing logics from
MCInstPrinter into a separate class inherited by both AsmPrinter and
MCInstPrinter, in which the derived classes only need to provide
primitives like printOperand and printDisp.

This change is basically NFC. See D143529 for changes on AsmPrinter.

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

Given the memory group, we are unlikely to need a huge page map to
record entire region. This CL reduces the size of default page map
buffer from 2048 to 512 and increase the number of static buffers to 2.

Reviewed By: cferris

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

The indeces of the dependent loops are properly ordered, just start from
1, so need just subtract 1 to get correct loop index.

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

Reviewed By: ldionne, #libc, #libc_abi

Spies: #libc_vendors, smeenai, libcxx-commits

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

When a derived-type as no component, its elem_len will be set to
zero when emboxed. Update the function to let empty derived-type
pointer/target succeed the test.

Example extracted from gfortran test pointer_init_8

```
module m
  type :: c
  end type c
  type, extends(c) :: d
  end type d
  type(c), target :: x
end module

use m
  class(c), pointer :: px => x

  if (.not. associated(px, x))   STOP 1
end
```

Reviewed By: klausler

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

During the implementation of P2286 a second Unicode decoder was added.
The original decoder was only used for the width estimation. Changing
an ill-formed Unicode sequence to the replacement character, works
properly for this use case. For P2286 an ill-formed Unicode sequence
needs to be formatted as a sequence of code units. The exact wording in
the Standard as a bit unclear and there was odd example in the WP. This
made it hard to use the same decoder. SG16 determined the odd example in
the WP was a bug and this has been fixed in the WP.

This made it possible to combine the two decoders. The P2286 decoder
kept track of the size of the ill-formed sequence. However this was not
needed since the output algorithm needs to keep track of size of a
well-formed and an ill-formed sequence. So this feature has been
removed.

The error status remains since it's needed for P2286, the grapheme
clustering can ignore this unneeded value. (In general, grapheme
clustering is only has specified behaviour for Unicode. When the string
is in a non-Unicode encoding there are no requirements. Ill-formed
Unicode is a non-Unicode encoding. Still libc++ does a best effort
estimation.)

There UTF-8 decoder accepted several ill-formed sequences:
- Values in the surrogate range U+D800..U+DFFF.
- Values encoded in more code units than required, for example 0+0020
  in theory can be encoded using 1, 2, 3, or 4 were accepted. This is
  not allowed by the Unicode Standard.
- Values larger than U+10FFFF were not always rejected.

Reviewed By: #libc, ldionne, tahonermann, Mordante

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

Check we write to the entire memory span of the inlined memset

Simplifies future update_llc_test_checks regenerations

Funnel fetching and building LLVM instructions into GettingStarted.

Modernize the build steps a little.

Remove comments saying CMAKE_BUILD_TYPE defaults to Debug as that's not true anymore (must explicitly pass it).

Reviewed By: MaskRay, hans

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

Integers are ambiguous as to whether it's an index or an FP value
without a decimal.

Looks like maybe AArch64 equivalent treates integers in hex as
index and any other integer as a FP value without a decimal. We
need to work with the RVI community to decide what we should do.

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