Shows failure to fold sel(sra(X,C1),sra(Y,C1)) -> sra(sel(X,Y),C1) (and to retain the flags)

The last use was removed on Apr 28, 2014 in commit
c5a3139e.

As discussed on D106058 - we're not propagating the common flags to the merged binop

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

Broke ASAN buildbot, will reland with fixes

This reverts commit b5a6ad8c.

I'm going to extend the functionality started in D106058 so move the folds into their own method to reduce the amount of code in DAGCombiner::visitSELECT

Currently when we compile the project in debug mode, `-g` will not be added to
compilation flag. The bc files generated in different mode are of different size.
When using GPU debuggers like `cuda-gdb`, it is expected to provide more info
with a debug version of bc lib.

Reviewed By: JonChesterfield

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

[X86][SSE] matchShuffleWithPACK - avoid poison pollution from bitcasting multiple elements together.

D106053 exposed that we've not been taking into account that by bitcasting smaller elements together and then performing a ComputeKnownBits on the result we'd be allowing a poison element to influence other neighbouring elements being used in the pack. Instead we now peek through any existing bitcast to ensure that the source type already matches the width source of the pack node we're trying to match.

This has also been a chance to stop matchShuffleWithPACK creating unused nodes on the fly which could affect oneuse tests during shuffle lowering/combining.

The only regression we're seeing is due to being unable to peek through a bitcast as its on the other side of a extract_subvector - which should go away once we finally allow shuffle combining across different vector widths (by making matchShuffleWithPACK using const SelectionDAG& we've gotten closer to this - see PR45974).

At most these use the StringRef/Twine wrappers and don't have any implicit uses of std::string.

Move the include down to any cpp implementation where std::string is actually used.

This pattern is visible in unrolled and vectorized loops.
Although the backend seems to be able to reassociate to
ideal form in the examples I looked at, we might as well
do that in IR for efficiency.

Still WIP, based on the Kaleidoscope/BuildingAJIT/Chapter4.

Reviewed By: lhames

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

Cross-compiling MLIR with MINGW failed because adding libMLIR to the libraries to link against would lead to duplicated symbols.

```
[09:28:14] ninja: job failed: : && /opt/bin/i686-w64-mingw32-libgfortran4-cxx03/i686-w64-mingw32-g++ --sysroot=/opt/i686-w64-mingw32/i686-w64-mingw32/sys-root/  -remap -D__USING_SJLJ_EXCEPTIONS__ -D__CRT__NO_INLINE -fno-gnu-unique -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment  -O2 -DNDEBUG   -shared -o bin/libMLIRPublicAPI.dll -Wl,--out-implib,lib/libMLIRPublicAPI.dll.a -Wl,--major-image-version,0,--minor-image-version,0 tools/mlir/lib/CAPI/IR/CMakeFiles/obj.MLIRCAPIIR.dir/AffineExpr.cpp.obj tools/mlir/lib/CAPI/IR/CMakeFiles/obj.MLIRCAPIIR.dir/AffineMap.cpp.obj tools/mlir/lib/CAPI/IR/CMakeFiles/obj.MLIRCAPIIR.dir/BuiltinAttributes.cpp.obj tools/mlir/lib/CAPI/IR/CMakeFiles/obj.MLIRCAPIIR.dir/BuiltinTypes.cpp.obj tools/mlir/lib/CAPI/IR/CMakeFiles/obj.MLIRCAPIIR.dir/Diagnostics.cpp.obj tools/mlir/lib/CAPI/IR/CMakeFiles/obj.MLIRCAPIIR.dir/IntegerSet.cpp.obj tools/mlir/lib/CAPI/IR/CMakeFiles/obj.MLIRCAPIIR.dir/IR.cpp.obj tools/mlir/lib/CAPI/IR/CMakeFiles/obj.MLIRCAPIIR.dir/Pass.cpp.obj tools/mlir/lib/CAPI/IR/CMakeFiles/obj.MLIRCAPIIR.dir/Support.cpp.obj tools/mlir/lib/CAPI/Registration/CMakeFiles/obj.MLIRCAPIRegistration.dir/Registration.cpp.obj tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPILinalg.dir/Linalg.cpp.obj tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPISCF.dir/SCF.cpp.obj tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPIShape.dir/Shape.cpp.obj tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPIStandard.dir/Standard.cpp.obj tools/mlir/lib/CAPI/Dialect/CMakeFiles/obj.MLIRCAPITensor.dir/Tensor.cpp.obj tools/mlir/lib/CAPI/Transforms/CMakeFiles/obj.MLIRCAPITransforms.dir/Passes.cpp.obj  lib/libMLIR.dll.a  lib/libMLIRIR.a  lib/libMLIRParser.a  lib/libMLIRSupport.a  lib/libMLIRPass.a  lib/libMLIRCAPIIR.a  lib/libMLIRAffine.a  lib/libMLIRAffineEDSC.a  lib/libMLIRAffineTransforms.a  lib/libMLIRAffineUtils.a  lib/libMLIRArmNeon.a  lib/libMLIRArmSVE.a  lib/libMLIRAsync.a  lib/libMLIRAsyncTransforms.a  lib/libMLIRAVX512.a  lib/libMLIRComplex.a  lib/libMLIRGPU.a  lib/libMLIRLinalgAnalysis.a  lib/libMLIRLinalgEDSC.a  lib/libMLIRLinalg.a  lib/libMLIRLinalgTransforms.a  lib/libMLIRLinalgUtils.a  lib/libMLIRLLVMIRTransforms.a  lib/libMLIRLLVMIR.a  lib/libMLIRLLVMAVX512.a  lib/libMLIRLLVMArmNeon.a  lib/libMLIRLLVMArmSVE.a  lib/libMLIRNVVMIR.a  lib/libMLIRROCDLIR.a  lib/libMLIROpenACC.a  lib/libMLIROpenMP.a  lib/libMLIRPDL.a  lib/libMLIRPDLInterp.a  lib/libMLIRQuant.a  lib/libMLIRSCF.a  lib/libMLIRSCFTransforms.a  lib/libMLIRSDBM.a  lib/libMLIRShape.a  lib/libMLIRShapeOpsTransforms.a  lib/libMLIRSPIRV.a  lib/libMLIRSPIRVModuleCombiner.a  lib/libMLIRSPIRVConversion.a  lib/libMLIRSPIRVTransforms.a  lib/libMLIRSPIRVUtils.a  lib/libMLIRStandard.a  lib/libMLIRStandardOpsTransforms.a  lib/libMLIRTensor.a  lib/libMLIRTensorTransforms.a  lib/libMLIRTosa.a  lib/libMLIRTosaTransforms.a  lib/libMLIRVector.a  lib/libMLIRCAPIIR.a  lib/libMLIRLinalg.a  lib/libMLIRCAPIIR.a  lib/libMLIRSCF.a  lib/libMLIRCAPIIR.a  lib/libMLIRShape.a  lib/libMLIRCAPIIR.a  lib/libMLIRStandard.a  lib/libMLIRCAPIIR.a  lib/libMLIRTensor.a  lib/libMLIRTransforms.a  lib/libMLIRAsync.a  lib/libMLIRAffineUtils.a  lib/libMLIRLinalgAnalysis.a  lib/libMLIRLinalgEDSC.a  lib/libMLIRVectorToSCF.a  lib/libMLIRVectorToLLVM.a  lib/libMLIRArmNeonToLLVM.a  lib/libMLIRArmNeon.a  lib/libMLIRLLVMArmNeon.a  lib/libMLIRAVX512ToLLVM.a  lib/libMLIRAVX512.a  lib/libMLIRLLVMAVX512.a  lib/libMLIRArmSVEToLLVM.a  lib/libMLIRArmSVE.a  lib/libMLIRLLVMArmSVE.a  lib/libMLIRStandardToLLVM.a  lib/libMLIRTargetLLVMIRModuleTranslation.a  lib/libMLIRLLVMIRTransforms.a  lib/libMLIRLLVMIR.a  lib/libMLIROpenMP.a  lib/libMLIRTranslation.a  lib/libMLIRSPIRVConversion.a  lib/libMLIRSPIRV.a  lib/libMLIRParser.a  lib/libMLIRTransforms.a  lib/libMLIRVector.a  lib/libMLIRAffineEDSC.a  lib/libMLIRLinalg.a  lib/libMLIRCopyOpInterface.a  lib/libMLIRTosa.a  lib/libMLIRQuant.a  lib/libMLIRTransformUtils.a  lib/libMLIRLoopAnalysis.a  lib/libMLIRPresburger.a  lib/libMLIRRewrite.a  lib/libMLIRPDLToPDLInterp.a  lib/libMLIRPass.a  lib/libMLIRAnalysis.a  lib/libMLIRAffine.a  lib/libMLIRSCF.a  lib/libMLIRLoopLikeInterface.a  lib/libMLIRPDLInterp.a  lib/libMLIRPDL.a  lib/libMLIRInferTypeOpInterface.a  lib/libMLIRStandard.a  lib/libMLIRTensor.a  lib/libMLIREDSC.a  lib/libMLIRCastInterfaces.a  lib/libMLIRVectorInterfaces.a  lib/libMLIRSideEffectInterfaces.a  lib/libMLIRDialect.a  lib/libMLIRViewLikeInterface.a  lib/libMLIRCallInterfaces.a  lib/libMLIRControlFlowInterfaces.a  lib/libMLIRIR.a  lib/libMLIRSupport.a  lib/libLLVM.dll.a  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && :
[09:28:14] lib/libMLIRAffine.a(AffineOps.cpp.obj):AffineOps.cpp:(.text+0x1d600): multiple definition of `mlir::AffineDialect::initialize()'
[09:28:14] lib/libMLIR.dll.a(d008729.o):(.text+0x0): first defined here
[09:28:14] lib/libMLIRArmSVE.a(ArmSVEDialect.cpp.obj):ArmSVEDialect.cpp:(.text+0x5be0): multiple definition of `mlir::arm_sve::ArmSVEDialect::initialize()'
[09:28:14] lib/libMLIR.dll.a(d039020.o):(.text+0x0): first defined here
[09:28:14] lib/libMLIRAsync.a(Async.cpp.obj):Async.cpp:(.text+0xc0d0): multiple definition of `mlir::async::AsyncDialect::initialize()'
[09:28:14] lib/libMLIR.dll.a(d023173.o):(.text+0x0): first defined here
...
```

Reviewed By: stellaraccident

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

This patch handles the `std::swap` function specialization
for `std::unique_ptr`. Implemented to be very similar to
how `swap` method is handled

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

Add a small power 2 srem test to match existing sdiv test. Add
larger power of 2 test to both.

The larger constant test shows materialization of a constant
for an AND in the RV64 code. We should be using W shift instructions
to match the RV32 code.

DebugInfo: Name class templates with default arguments consistently (both direct naming, and as a template argument for a function template)

It's noteworthy that GCC has the same bug here, which is a bit
surprising. Both Clang and GCC's bug is only for function template
arguments that are themselves templates with default template arguments
(f1<t1<int[, missing_default_here]>>). Probably because function name
matching isn't generally necessary - whereas type matching is necessary
for DWARF consumers to associate declarations and definitions across
translation units, so the bug's been addressed there already - but
continued to exist for function templates since it's fairly benign
there.

I came across this while working on a change that could reconstitute
these pretty printed names based on the rest of the DWARF, reducing the
size of the DWARF by not having to encode all the template parameters in
the name string. That reconstitution code can't tell the difference
between a defaulted argument or not, so couldn't create the current
buggy-ish output.

Making the names more consistent between direct and indirect references,
and between function and class templates seems all to the good.

(I fixed the function template version of this a few years back in
9fdd09a4 - clearly I should've looked
more closely and generalized the code better so it only had to be fixed
once - well, doing that here now)

llvm::KnownBits::byteSwap() and reverse() don't modify in-place, so
we weren't actually computing anything. This was causing a miscompile on an
arm64 stage2 bootstrap clang build.

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

Fix bug introduced in 2c68eccc,
the GEP type was off-by-ptr. Apparently I didn't run the MLIR
tests.

Corollary to 1113e068 this allows us to
match gather that dont produce a full vector width results. They use an
extended gather which is truncated back to the original type.

Rewrite patterns to assume that the operand of STEP_VECTOR is a
constant. The old patterns will stop working when the operand is changed
from a Constant to a TargetConstant. (See D105673.)

Add test coverage for certain patterns that weren't exercised by
existing regression tests.

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

This API is incompatible with opaque pointers and deprecated in
favor of the version that accepts an explicit element type.

Also remove the separate overload for a single index, as this is
already covered by the ArrayRef overload.

Remove uses of to-be-deprecated API. In cases where the correct
element type was not immediately obvious to me, fall back to
explicit getPointerElementType().

This API is incompatible with opaque pointers and deprecated in
favor of the version that accepts an explicit element type.

Remove uses of to-be-deprecated API.

Unfortunately this one mostly just makes the use of
getPointerElementType() explicit, as the correct type to use
wasn't immediately available (deriving it from QualType is left
as an excercise to the reader).

Background: https://reviews.llvm.org/D82490#inline-1007741

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

ICF previously operated only within a given OutputSection. We would
merge all CFStrings first, then merge all regular code sections in a
second phase. This worked fine since CFStrings would never reference
regular `__text` sections. However, I would like to expand ICF to merge
functions that reference unwind info. Unwind info references the LSDA
section, which can in turn reference the `__text` section, so we cannot
perform ICF in phases.

In order to have ICF operate on InputSections spanning multiple
OutputSections, we need a way to distinguish InputSections that are
destined for different OutputSections, so that we don't fold across
section boundaries. We achieve this by creating OutputSections early,
and setting `InputSection::parent` to point to them. This is what
LLD-ELF does. (This change should also make it easier to implement the
`section$start$` symbols.)

This diff also folds InputSections w/o checking their flags, which I
think is the right ...

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

This patch fixed two issues found when folding `__kmpc_is_spmd_exec_mode`:
1. When the reaching kernels are empty, it should not fold to generic mode.
2. When creating AA for the caller when updating information, the dependency
   should be required.

Reviewed By: ye-luo

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

This API is incompatible with opaque pointers and deprecated in
favor of the version that accepts an explicit element type.

Remove uses of to-be-deprecated API.

Reviewed By: frasercrmck

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

This API is incompatible with opaque pointers and deprecated in
favor of the version that accepts an explicit element type.

Remove uses of to-be-deprecated API. I've fallen back to calling
getPointerElementType() in some cases where the correct type wasn't
immediately obvious to me.

At most these use the StringRef/Twine wrappers and don't have any implicit uses of std::string.

Move the include down to any cpp implementation where std::string is actually used.

This API is incompatible with opaque pointers and deprecated in
favor of the version that accepts an explicit element type.

Remove uses of to-be-deprecated API.