This infinite looped after d8127b2b

If a dimension does not appear in the permutation map of a vector
transfer op, the size of the accessed slice in that dimension is `1`.
Before this fix, `getTransferChunkAccessed` used to return `0` for such
dimensions, which would means that `0` elements in the underlying
tensor/memref are accessed.

Note: There is no test case that fails due to this bug and because this
interface method is currently only used in one place, it is hard to
write a regression test. This fix is in preparation of subset hoisting
functionality that will be added in subsequent commits.

Update the remaining tests for matrix multiplication (_matmul_) in:

  * vector-contract-to-outerproduct-transforms.mlir

with cases for scalable vectors.

Note that in order for the "vector.contract -> vector.outerproduct"
patterns to work, only the non-reduction dimension can be scalable (*).
For Matmul operations that is set to be the N dimension (i.e. rows of
the output matrix), which matches how matrix multiplication are normally
implemented for e.g. Arm's SVE. However, making the M dimension scalable
(i.e. columns of the output matrix) should work as well.

Making both parellel dimensions scalable is left as a TODO for when
support for 2-D scalable vectors is more established (this is
work-in-progress as part of the effort to support Arm's SME in MLIR).

The change in:

  * `UnrolledOuterProductGenerator`

is a "bug fix" to make sure that the conversion pattern correctly
propagates scalability when creating `arith.extf` operations.

(*) The conversion tested in this file unrolls along the reduction
dimension, which is not supported for scalable vectors.

Update evaluate::ActualArgument to propagate the %VAL and %REF markers
until lowering.
Semantic checks are added to %VAL to ensure the argument is a numerical
or logical scalar.

I did not push these markers into the characteristics because other
compilers do not complain about inconsistent usages (e.g. using %VAL in
a call on a procedure with an interface without VALUE dummies is not
flagged by any compilers I tested, and it is not an issue for lowering,
so I decided to stay simple here and minimize the footprint of these
legacy features).

Lowering retrieves these markers and does the right thing: pass %VAL in
registers and pass %REF by address without adding any extra arguments
for characters.

The main README.md should probably be kept pretty short and be used to
point new-comers to the most essential ways to get started on or get
involved with LLVM.

Therefore, this patch removes a pointer to IRC (not used very much these
days), and does add pointers to office hours and online sync-ups.

While extracting the existing functionality into a function, one of the
variable usages wasn't correctly updated.

Solves crash mentioned in #65920.

The front-end is making implicit conversions explicit in assignment and
structure constructors.

While this generally helps and is needed by semantics to fold structure
constructors correctly, this is incorrect when the LHS or component is
an allocatable. The RHS may have non default lower bounds that should be
propagated to the LHS, and making the conversion explicit changes the
semantics. In the structure constructor, the situation is even worse
since Fortran 2018 7.5.10 point 7 allows the value to be a reference to
an unallocated allocatable, and adding an explicit conversion in
semantics will cause a segfault.

This patch removes the explicit convert in semantics when the
LHS/component is a whole allocatable, and update lowering to deal with
the conversion insertion, dealing with preserving the lower bounds and
the tricky structure constructor case.

Revert "[libc++][tests] Fix a few remaining instances of outdated static assertion regexes in our test suite"

Fails like https://lab.llvm.org/buildbot/#/builders/238/builds/6278/steps/11/logs/stdio on many bots.

This reverts commit 166b3a86.

GPRF64 represents a pair of registers. We were only copying the even
part. We need to copy the odd part too.

Two `OpOperand`s are the same if they belong to the same owner and have
the same operand number. There are currently no comparison operators
defined on `OpOperand` and we work around this in multiple places by
comparing pointers.

Note: `OpOperand`s are stored in an op, so it is valid to compare their
pointers to determine if they are the same operand. E.g.,
`getOperandNumber` is also implemented via pointer arithmetics.

isSmallestNormalized() only considers the magnitude, not the sign.

We can only use fli for the positive normalized value.

https://reviews.llvm.org/D146358 was assuming that all subobjects have
their own name (`SubobjectDecl`), but it was not true for array
elements.

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

Leak could be real, as the code terminates before freeing the memory.

This patch fixes the various crashlog test failures following
ec456ba9

, which renamed the process member variable in the Scripted
Thread python base class.

This patch updates the crashlog scripted process implementation to
reflect that change.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

* Consider the darker/clang-format command to have failed if the exit
   code is non-zero, regardless of the stdout/stderr output.
* Propagate stderr from the formatter command to the script's
   caller (and into the GitHub log).
* On success, dump stdout to the caller, so it ends up in GitHub's log.
   I'm not sure what this would ever be, but if it exists, it should be
   preserved.
* Just before the script exits, if any formatter failed, print a line
   showing which formatters failed.

Renaming cds-> cdsort for consistency. This is NFC unless somebody uses
older names

The interesting stuff is of course still coming ;-)

These tests all need an x86 backend for the correct data layout.

This reverts commit ddbaa11e.

Reapply the original commit, the broken test was repaired in 5e51363f in the meantime.

This reverts commit c2a1249a.

The MLIR bots are broken with an omp test failure.

This also renames DoubleXLenLLT to sDoubleXLen.

Changes:

1. For both dimToLvl and lvlToDim, always returns the actual map instead
of AffineMap() for identity map.
2. Updated custom builder for encoding to have default values.
3. Non-inferable lvlToDim will still return AffineMap() during
inference, so it will be caught by verifier.