All of the places that use the Classes array, use it as a uptr.
So change the array to be uptr instead of u32.

Reviewed By: Chia-hungDuan

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

This was added originally as the test was failing on NVPTX before an
explicit target triple was set on the llc invocation. The test was fixed
in 4afb1ee7 but the unsupported
directive was never removed.

This fixed a test failure that caused the rollback of the original
commit. Verified with ninja check-mlir.

The LLVM-libc build itself will override include paths and prefer it's
own limits.h over the compiler's limits.h. Because we rely on the
compiler limits.h for numerical limits in LLVM-libc it needs to be
include_next:ed if not already included. The other method to work
around this is to define all numeric macros in place.

Signed-off-by: Alfred Persson Forsberg <cat@catcream.org>

Reviewed By: thesamesam

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

This reverts commit 1670e0ea.
Causes https://lab.llvm.org/buildbot/#/builders/188/builds/33943

Because the code layout is not known during compilation, the distance of
cross-section jumps is not knowable at compile-time. Because of this, we
should assume that any cross-sectional jumps are out of range. This
assumption is necessary for machine function splitting on AArch64, which
introduces cross-section branches in the middle of functions. The linker
relaxes out-of-range unconditional branches, but it clobbers X16 to do
so; it doesn't relax conditional branches, which must be manually
relaxed by the compiler.

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

This change writes the module name to the name section of the wasm
binary.  We use the `-soname` argument to determine the name and we
default the output file basename if this option is not specified.

In the future we will likely want to embed the soname in the dylink
section too, but this the first step in supporting `-soname`.

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

Machine function splitting will become available for AArch64; since MFS
is no longer X86-only, the tests for generic behavior should live
somewhere other than tests/CodeGen/X86.

MFS implementation doesn't vary much across platforms, and most tests
should be identical between X86 and AArch64 besides instruction
selection, so the tests can live together in tests/CodeGen/Generic.

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

Watching https://green.lab.llvm.org/green/job/clang-stage1-RA/

This adds extension Zicfilp and support pseudo instruction lpad.

Reviewed By: craig.topper

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

Direct IR supports pack, but libgen parth did not until
this was added in https://reviews.llvm.org/D158012

Reviewed By: Peiming

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

If we don't do this then we end up with symbols that refer to
non-existent segments.

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

Also while here sync the header paths with the Haiku GCC configuration.

Added: /boot/system/develop/headers/gnu
Removed: /boot/system/develop/headers/os/arch

https://github.com/haikuports/haikuports/tree/master/sys-devel/gcc/patches

Reviewed By: nielx

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

This often breaks modules-enabled bootstrap builds.

This splits the backend and assemble actions for HLSL inputs and
handles the options in GetNamedOutputPath instead of aliasing `-o`.
This also moves how we default to emitting asm to stdout, since doing
this in the HLSL toolchain rather than the driver pollutes how the
clang driver works as well.

When both options are specified we disable collapsing the assemble
action and attempt to generate both outputs. Note that while this
handles the driver aspects, we can't actually run in that mode for now
since -cc1as doesn't understand DXIL as an input yet.

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

To guarantee accuracy for all potential float values, this patch adds a
fuzzer to compare the results for float conversions from our printf
against MPFR's.

Reviewed By: lntue

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

Fuzzing revealed bugs in the %e and %g conversions. Since these are very
similar, they are grouped together. Again, most of the bugs were related
to rounding. As an example, previously the code to check if the number
was truncated only worked for digits below the decimal point, due to it
being originally designed for %f. This patch adds a mechanism to check
the digits above the decimal point for both %e and %g.

Reviewed By: sivachandra, lntue

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

Fuzzing revealed several bugs in the %f float conversion. This patch
fixes them. Most of these bugs are related to rounding, such as
1.999...999 being rounded to 2.999...999 instead of 2.000...000 due to
rounding up not properly changing the nines to zeros. Additionally, much
of the rounding infrastructure has been refactored out so it can be
shared with the other conversions.

Reviewed By: sivachandra

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

The trailing zeroes were previously not counted when calculating the
padding, which caused a high-precision number to get too much padding.

Reviewed By: sivachandra

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

In the same way that get_explicit_mantissa is used to get the mantissa
with all the implicit bits spelled out, get_explicit_exponent gives you
the exponent with the special cases handled. Mainly it handles the cases
where the exponent is zero, which causes the exponent to either be 1
higher than expected, or just 0.

Reviewed By: lntue

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

Rather than redefine --help, /help, -D, and /D, just use the existing
options.

This reverts commit 5d169572.

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

This reverts commit 02596693.
This reverts commit 3c5b4dab.

The build is broken:

mlir/test/lib/Dialect/Test/TestOps.td:988:7: error: Value specified for template argument 'Pat:supplemental_results' is of type dag; expected type list<dag>: (addBenefit 10)
def : Pat<(OpD $input), (OpF $input), [], (addBenefit 10)>;
      ^

This patch picks up where https://reviews.llvm.org/D157159 left of, but
allows for concurrent reads/writes, but protects setting up and tearing
down the underlying Connection object.

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

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

Emit warnings when `InstrProfCorrelator` finds problems with debug info for lightweight instrumentation profile correlation. To prevent excessive printing, only emit the first 5 warnings.

In addition, remove a diagnostic about missing debug info in `InstrProfiling.cpp`. Some compiler-generated functions, e.g., `__clang_call_terminate`, does not emit debug info and will fail a build if `-Werror` is used. This warning is not actionable by the user and I have not seen non-compiler-generated functions fail this test.

Reviewed By: smeenai

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

The usage of this variable was removed in `4f14c17d`.

This is no longer used inside this file. Since the call to
`GetPersistentExpressionStateForLanguage` has side-effects I marked this
NFCI. But there is no good reason we need this here.

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

Previously types such as `SmallVector<clang::Attr, 4> *` would
trigger the assertion inside the `SmallVector` formatter:
```
assert self.type_size != 0
```
This happens because `the_type.GetTemplateArgumentType(0)` returns
`None` (since `the_type` is a pointer to the `SmallVector`).

This patch dereferences `the_type` if it's a pointer type. We do this
for references already.

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

InstCombine already put these back together so there's no visible
change in the -O1 test for the header.

The name says it shouldn't be not inf, not eq inf.

I've been struggling with generating the C++ class declarations and definitions for custom attributes from TableGen, as described on this documentation page: https://mlir.llvm.org/docs/DefiningDialects/AttributesAndTypes/#adding-a-new-attribute-or-type-definition

The code for custom types is automatically generated when the MLIR Dialect is added with `add_mlir_dialect()` in the CMake file.

The same is not the case for custom attributes. I think people could benefit from learning how to adjsut their CMakeLists.txt to automatically generate the classes as described on that documentation page. This change adds the necessary information for this.

makslevental on Discord was so kind to help me figure this out myself

Reviewed By: makslevental

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

This is a big refactor of the clang driver's option handling to use
the Visibility flags introduced in https://reviews.llvm.org/D157149.
There are a few distinct parts, but they can't really be split into
separate commits and still be made to compile.

1. We split out some of the flags in ClangFlags to ClangVisibility.
   Note that this does not include any subtractive flags.

2. We update the Flag definitions and OptIn/OptOut constructs in
   Options.td by hand.

3. We introduce and use a script, update_options_td_flags, to ease
   migration of flag definitions in Options.td, and we run that on
   Options.td. I intend to remove this later, but I'm committing it so
   that downstream forks can use the script to simplify merging.

4. We update calls to OptTable in the clang driver, cc1as, flang, and
   clangd to use the visibility APIs instead of Include/Exclude flags.

5. We deprecate the Include/Exclude APIs and add a release note.

*if you are ...

I don't have a test case for this but noticed this warning when including system headers with `-I` rather than `-isystem`.

```
In file included from <built-in>:1:
In file included from /nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_runtime_wrapper.h:157:
/nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_math.h:39:25: warning: extra tokens at end of #ifdef directive [-Wextra-tokens]
                        ^
```

Reviewed By: tra

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

This adds a parameter SupplementalPatterns in tablegen class Pattern for
postprocessing code. For example, this can be used to ensure ops are
placed in the correct device by copying the atttributes that decide
devicement placement in Tensorflow dialect to prevent performance
regression.

Reviewed By: jpienaar

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