SLP/TTI do not know about the cost estimation for addsub pattern,
supported by X86. Previously the support for pattern detection was added
(seeTTI::isLegalAltInstr), but the cost still did not estimated
properly.

Using ContantInt::get will zero extend.

Fixes #76441

Add missing array initialization as the array was not initialized and
the value zero was assumed.

We don't need to pass in the register class, we can get it from the
LMULInfo.

Use an explicit list of LMULInfos instead of indexing part of other
lists. Use wvrclass field to double LMUL instead of using two lists.

Use range instead of list in another spot. I wish I could use a list of
LMULInfo here but there's no way to quadruple an LMUL yet.

Added SCFDialect to mlir-vulkan-runner cc_binary.

This test fails on some internal buildbot machines / setups. Disable for
now and to fix later.

This commit adds an assert in one of the CallOp builders to ensure it is not use to create an indirect call. Otherwise, the callee type would include the callee pointer type which is handed in as first argument.

1. Register SCFDialect in mlir-vulkan-runner
2. Add SCFToSPIRV in GPUToSPIRVPass to lower scf.

Fixes https://github.com/llvm/llvm-project/issues/74939

fold bf16_to_fp(op & 0xffff) -> bf16_to_fp(op)

This is needed to protect against global overflows, which was found by a
fuzzer recently.

Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65283



---------

Signed-off-by: David Korczynski <david@adalogics.com>

[clang-tidy][misleading-indentation]ignore false-positives for line started with empty macro (#75061)

Fixes: #71767

Big-endian is not supported on aarch64 and x86 yet. Try to fix
buildbot failure on ppc64be, https://lab.llvm.org/buildbot/#/builders/93/builds/18057.

These tests generally use one printf for each field of
RawInstrProf::ProfileData except the lines being touched in this
patch.  These lines print two fields, namely NumValueSites and
NumBitmapBytes, with one printf, which is very confusing.  (Note that
the 4-byte printf at the end of the group is padding to make the
struct size a multiple of 8 bytes.)

This patch makes the tests a litle more readable by splitting
NumValueSites and NumBitmapBytes into two separate lines.

This patch is to extract the NFC in #76319 into a separate commit.

We lower overflow arithmetics to its M68kISD counterparts that produce
results of {i16/i32, i8} in which the second resut represents CCR. In
the event where we're certain there won't be an overflow, for instance
8 & 16-bit multiplications, we simply use zero in replacement of the
second result.
This patch replaces M68kISD::CMOV that takes this kind of zero or
all-ones CCR as condition value with its corresponding operand value.

M68k only has 16-bit x 16-bit -> 32-bit variant for multiplications
taking 16-bit operands. We still define two input operands for this
class of instructions, and tie the first operand to the result value.
The problem is that the two operands have different register classes
(DR32 and DR16) hence making these instructions communitive produces
invalid MachineInstr (though the final assembly will still be correct).

So the structure of TableGen files is still clear.

```
llvm-project/mlir/lib/Analysis/Presburger/GeneratingFunction.h:56:28:
error: unused variable 'term' [-Werror,-Wunused-variable]
   56 |     for (const ParamPoint &term : numerators)
      |                            ^~~~
1 error generated.
```

It's unnecessary to defaultly pass feature `-save-restore`, since risc-v
backend defaultly disables save-restore functionality.

he spimm operand is an immediate whose only 4-5th bit could be setted
and not based on rlist operand

Emit relax relocs when expand non-large la.pcrel and non-large la.got on
llvm-mc stage, which like what does on GAS.
1, la.pcrel -> PCALA_HI20 + RELAX + PCALA_LO12 + RELAX
2, la.got -> GOT_PC_HI20 + RELAX + GOT_PC_LO12 + RELAX

The compiler doesn't USE-associate names of intrinsic procedures from
modules (in the absence of ONLY:), so that the associating scope doesn't
get populated with names of intrinsics that were used only in
declarations (e.g., SELECTED_REAL_KIND). A recent bug report (below)
shows that we should modify that policy in the case of names that appear
in explicit INTRINSIC attribute statements. The behaviors of other
Fortran compilers are not consistent and the requirements of the
standard are not clear; this fix follows the precedent set by gfortran
and nvfortran.

Fixes https://github.com/llvm/llvm-project/issues/72084.

llvm-project/mlir/lib/Analysis/Presburger/QuasiPolynomial.cpp:29:39:
 error: unused variable 'aff' [-Werror,-Wunused-variable]
    for (const SmallVector<Fraction> &aff : term) {
                                      ^
1 error generated.

When rounding what otherwise would have been a result that underflowed
to zero up (RU) or down (RD) to the least magnitude nonzero subnormal
number, ensure that the original exponent value doesn't perturb the
result.

The Fortran standard says that overflow input cases in some rounding
modes (RZ, RD, RU) should round to a "representable" number. Some
Fortran compilers interpret this to mean +/-HUGE(), some as +/-Inf.
Follow the precedent of gfortran and the Intel compilers.

If list-directed input contains a repeated item ("20*123.0") that is not
fully consumed by the READ statement's data item list, the end of that
READ statement was repositioning the input to the repeated value
("123.0"), leading to later confusion. Cancel the input item repetition
during EndIoStatement() processing to prevent this misbehavior.

Fixes llvm-test-suite/Fortran/gfortran/regression/list_read_4.f90.

Ensure that any buffered data has tranferred to an external unit before
measuring its file size.

Embarrassingly, the runtime was returning UNKNONN rather than UNKNOWN
for things like INQUIRE(..., FORMAT=).

When the result of NEAREST() has an exponent less than that of the
argument (e.g., NEAREST(1.,-1.) and NEAREST(-1.,1.)), the result was
wrong, because the increment value uses the result of SPACING() in terms
of the argument. Fix by just calling into the C runtime routine
std::nextafter().

When generalized numeric output editing of real data maps to Fw.d output
editing, either two or four trailing blanks are emitted depending on the
presence and value of 'e'. The code that detects field width overflow
didn't take these trailing blanks into account, and sometimes the field
width adjustment was producing an F0.d output edit descriptor (no fixed
field width). Fix by retaining the original field width, but requiring
it to also accommodate the trailing blanks.

Fixes llvm-test-suite/Fortran/gfortran/regression/fmt_g.f.

When FINDLOC() can't find its target value among the unmasked array
elements, it must return a zero result. Its implementation doesn't
sufficiently distinguish a zero result from a hit in an array with lower
bound(s) less than one. Fix by adding a flag to distinguish the case
with no hits from cases with hits.

Fixes llvm-test-suite/Fortran/gfortran/regression/findloc_6.f90.

It would surprise me if this case ever arose outside a couple of tests
in llvm-test-suite/Fortran/gfortran/regression (namely
cshift_large_1.f90 and eoshift_large_1.f90), but now at least those
tests will pass.