[mlir][Linalg] Uniformize SplitReduction transforms and add option to use Bufferization::AllocTensor

This revision merges the 2 split_reduction transforms and adds extra control by using attributes.

SplitReduction is known to require a concrete additional buffer to store tempoaray information.
Add an option to introduce a `bufferization.alloc_tensor` instead of `linalg.init_tensor`.
This behaves better with subset-based tiling and bufferization.

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

The assert was added with 0399473d and is correct for that
pattern, but it is off-by-1 with the enhancement in d4f39d83.

The transforms are still correct with the new pre-condition:
https://alive2.llvm.org/ce/z/6_6ghm
https://alive2.llvm.org/ce/z/_GTBUt

And as shown in the new test, the transform is expected with
'ult' - in that case, the icmp reduces to test if the shift
amount is 0.

This allows all constant folding to happen through a single
function, without requiring special handling for loads at each
call-site.

This may not be NFC because some callers currently don't do that
special handling.

This is a follow up to my previous commit where TestSTL.py got broken
due to 9c6e0435.
Now that we force dwarf symbols by default on windows we dont need to
specifically put -gdwarf O0 in debug flags for this test.

These are not mentioned in the OpenCL C Specification nor in the
OpenCL Extension Specification.

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

The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated alloca instructions as well as meaningless stores and
this behavior can leave unused (dead) arguments.

The test shows that the arguments are not removed in the current
optimization pipeline.

Missed these in 41f0b6a7, resulting
in unconditional debug output.

Use a common ConstantFoldInstOperands-based constant folding
implementation, instead of specifying the folding function for
each function individually. Going through the generic handling
doesn't appear to have any significant compile-time impact.

As the test change shows, this is not NFC, because we now use
DataLayout-aware constant folding, which can do slightly better
in some cases (e.g. those involving GEPs).

Reviewed By: nikic

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

TestSTL.py was broken by 9c6e0435.
This patch fixes it with changes to its Makefile.

This is split from D113107 to address #56204 and https://discourse.llvm.org/t/how-to-build-compiler-rt-for-new-x86-half-float-abi/63366

Reviewed By: zahiraam, rjmccall, bkramer, MaskRay

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

For instructions that don't need any special handling, use
ConstantFoldInstOperands(), rather than re-implementing individual
cases.

This is probably not NFC because it can handle cases the previous
code missed (e.g. vector operations).

Support compares in ConstantFoldInstOperands(), instead of
forcing the use of ConstantFoldCompareInstOperands(). Also handle
insertvalue (extractvalue was already handled).

This removes a footgun, where many uses of ConstantFoldInstOperands()
need a separate check for compares beforehand. It's particularly
insidious if called on a constant expression, because it doesn't
fail in that case, but will just not do DL-dependent folding.

This test checks one of problematic cases outlined in D128006, leading
to the patch's reversal. I thought it best to add a test just in case
this sort of optimization is attempted again in the future in some
fashion.

Even though the array is declared with '*' upper bounds, it has an
initial value that has a statically known shape. Use the shape from
the type of the initializer when the declared size is '*'.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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



Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

Address fuzzer crash

Reviewed By: yota9

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

In some cases, there may be widened users of inductions even though the
plan includes the scalar VF. In those cases, make sure we still replace
the VPWidenIntOrFpInductionRecipe with scalar steps, as otherwise we may
try to execute a VPWidenIntOrFpInductionRecipe with a scalar VF.

Alternatively the patch could also split the range if needed.

This fixes a crash exposed by D123720.

Reviewed By: Ayal

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

The names of CHARACTER strings were being truncated leading to invalid
collisions and other failures. This change makes sure to use the entire
string as the seed for the unique name.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

This should have been part of D128666.

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

Generate INSTRINFO_OPERAND_TYPE table in X86GenInstrInfo.inc.

This diff adds support for instructions that were previously reported as having
memory access size 0. It replaces the heuristic of looking at instruction
register width to determine memory access width by instead checking the memory
operand type using tablegen-provided tables.

Reviewed By: skan

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

Currently, we only remove dead blocks and non-feasible edges in
IPSCCP, but not in SCCP. I'm not aware of any strong reason for
that difference, so this patch updates SCCP to perform the CFG
cleanup as well.

Compile-time impact seems to be pretty minimal, in the 0.05%
geomean range on CTMark.

For the test case from https://reviews.llvm.org/D126962#3611579
the result after -sccp now looks like this:

    define void @test(i1 %c) {
    entry:
      br i1 %c, label %unreachable, label %next
    next:
      unreachable
    unreachable:
      call void @bar()
      unreachable
    }

-jump-threading does nothing on this, but -simplifycfg will produce
the optimal result.

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

Here is a character SELECT CASE construct that requires a temp to hold the
result of the TRIM intrinsic call:

```
module m
      character(len=6) :: s
    contains
      subroutine sc
        n = 0
        if (lge(s,'00')) then
          select case(trim(s))
          case('11')
             n = 1
          case default
             continue
          case('22')
             n = 2
          case('33')
             n = 3
          case('44':'55','66':'77','88':)
             n = 4
          end select
        end if
        print*, n
      end subroutine
    end module m
```

This SELECT CASE construct is implemented as an IF/ELSE-IF/ELSE comparison
sequence.  The temp must be retained until some comparison is successful.
At that point the temp may be freed.  Generalize statement context processing
to allow multiple finalize calls to do this, such that the program always
executes exactly one freemem call.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: klausler, vdonaldson

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



Co-authored-by: V Donaldson <vdonaldson@nvidia.com>

Handle `for` statements without conditions.

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

Reviewed-by: xazax.hun, gribozavr2, li.zhe.hua

Follow up to D127894, new liveness update code needs to handle
the case where S_ANDN2 input must be extended through loops when
V_CNDMASK_B32 has been hoisted.

Reviewed By: arsenm

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

Follow-up to D128763.

A warning was recently introduced in [D128576](https://reviews.llvm.org/D128576) due to now unused lambda `function_name_from_load_address`. This warning causes build failures when treating warnings as errors. This change expands the comment to also include the definition of this lambda, fixing the warning.

Error:
```
[3809/6000] Building CXX object tools/lldb/source/Plugins/TraceExporter/common/CMakeFiles/lldbPluginTraceExporterCommon.dir/TraceHTR.cpp.o
FAILED: tools/lldb/source/Plugins/TraceExporter/common/CMakeFiles/lldbPluginTraceExporterCommon.dir/TraceHTR.cpp.o
/usr/bin/clang++ -DHAVE_ROUND -DLLDB_CONFIGURATION_DEBUG -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/__w/1/b/llvm/Debug/tools/lldb/source/Plugins/TraceExporter/common -I/__w/1/llvm-project/lldb/source/Plugins/TraceExporter/common -I/__w/1/llvm-project/lldb/include -I/__w/1/b/llvm/Debug/tools/lldb/include -I/__w/1/b/llvm/Debug/include -I/__w/1/llvm-project/llvm/include -I/__w/1/llvm-project/llvm/../clang/include -I/__w/1/b/llvm/Debug/tools/lldb/../clang/include -I/__w/1/llvm-project/lldb/source -I/__w/1/b/llvm/Debug/tools/lldb/source -isystem /usr/include/libxml2 -fPIC -fvisibility-inlines-hidden -Werror -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -g  -fno-exceptions -gsplit-dwarf -std=c++14 -MD -MT tools/lldb/source/Plugins/TraceExporter/common/CMakeFiles/lldbPluginTraceExporterCommon.dir/TraceHTR.cpp.o -MF tools/lldb/source/Plugins/TraceExporter/common/CMakeFiles/lldbPluginTraceExporterCommon.dir/TraceHTR.cpp.o.d -o tools/lldb/source/Plugins/TraceExporter/common/CMakeFiles/lldbPluginTraceExporterCommon.dir/TraceHTR.cpp.o -c /__w/1/llvm-project/lldb/source/Plugins/TraceExporter/common/TraceHTR.cpp
/__w/1/llvm-project/lldb/source/Plugins/TraceExporter/common/TraceHTR.cpp:136:8: error: unused variable 'function_name_from_load_address' [-Werror,-Wunused-variable]
  auto function_name_from_load_address =
```

Reviewed By: wallace

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

Linker optimization hints mark a sequence of instructions used for
synthesizing an address, like ADRP+ADD. If the referenced symbol ends up
close enough, it can be replaced by a faster sequence of instructions
like ADR+NOP.

This commit adds support for 2 of the 7 defined ARM64 optimization
hints:
- LOH_ARM64_ADRP_ADD, which transforms a pair of ADRP+ADD into ADR+NOP
  if the referenced address is within +/- 1 MiB
- LOH_ARM64_ADRP_ADRP, which transforms two ADRP instructions into
  ADR+NOP if they reference the same page

These two kinds already cover more than 50% of all LOHs in
chromium_framework.

Differential Review: https://reviews.llvm.org/D128093

`mov x0, 1024u` is permitted in binutils but rejected by the integrated
assembler. Support the case. This is especially important when using the C
pre-processor with the assembler: some shared code between C and assembler may
use lower-cased suffices.

Reviewed By: MaskRay

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

With libgcc, we follow the behavior of GCC for backwards compatibility,
only using --as-needed in the non-C++ mode.

With libunwind, there are no backward compatibility requirements so we
can always use --as-needed on all supported platforms.

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