This is still somehow a WIP, we have some issues with this interface
that are not trivial to solve. This patch tries to make the concepts of
RegionBranchPoint and RegionSuccessor more robust and aligned with their
definition:
- A `RegionBranchPoint` is either the parent (`RegionBranchOpInterface`)
op or a `RegionBranchTerminatorOpInterface` operation in a nested
region.
- A `RegionSuccessor` is either one of the nested region or the parent
`RegionBranchOpInterface`

Some new methods with reasonnable default implementation are added to
help resolving the flow of values across the RegionBranchOpInterface.

It is still not trivial in the current state to walk the def-use chain
backward with this interface. For example when you have the 3rd block
argument in the entry block of a for-loop, finding the matching operands
requires to know about the hidden loop iterator block argument and where
the iterargs start. The API is designed around forward-tracking of the
chain unfortunately.

Try to reland #161575 ; I suspect a buildbot incremental build issue.

Reverts llvm/llvm-project#161575

Broke Windows on ARM buildbot build, needs investigations.

This is still somehow a WIP, we have some issues with this interface
that are not trivial to solve. This patch tries to make the concepts of
RegionBranchPoint and RegionSuccessor more robust and aligned with their
definition:
- A `RegionBranchPoint` is either the parent (`RegionBranchOpInterface`)
op or a `RegionBranchTerminatorOpInterface` operation in a nested
region.
- A `RegionSuccessor` is either one of the nested region or the parent
`RegionBranchOpInterface`

Some new methods with reasonnable default implementation are added to
help resolving the flow of values across the RegionBranchOpInterface.

It is still not trivial in the current state to walk the def-use chain
backward with this interface. For example when you have the 3rd block
argument in the entry block of a for-loop, finding the matching operands
requires to know about the hidden loop iterator block argument and where
the iterargs start. The API is designed around forward-tracking of the
chain unfortunately.

- In the SCF Utils, add the `parallelLoopUnrollByFactors()` function to
unroll scf::ParallelOp loops according to the specified unroll factors
- Add a test pass "TestParallelLoopUnrolling" and the related LIT test
- Expose `mlir::parallelLoopUnrollByFactors()`,
`mlir::generateUnrolledLoop()`, and `mlir::scf::computeUbMinusLb()`
functions in the mlir/Dialect/SCF/Utils/Utils.h and /IR/SCF.h headers to
make them available to other passes.
- In `mlir::generateUnrolledLoop()`, add an optional `IRMapping *clonedToSrcOpsMap` 
argument to map the new cloned operations to their
original ones. In the function body, change the default `AnnotateFn`
type to `static const` to silence potential warnings about dangling
references when a function_ref is assigned to a variable with automatic
storage.

Signed-off-by: Fabrizio Indirli <Fabrizio.Indirli@arm.com>

Reverts llvm/llvm-project#163806 due to linking errors on the function
`mlir::scf::computeUbMinusLb`

- In the SCF Utils, add the `parallelLoopUnrollByFactors()` function
  to unroll scf::ParallelOp loops according to the specified unroll factors
- Add a test pass "TestParallelLoopUnrolling" and the related LIT test
- Expose `mlir::parallelLoopUnrollByFactors()`, `mlir::generateUnrolledLoop()`,
  and `mlir::scf::computeUbMinusLb()` functions in the
  mlir/Dialect/SCF/Utils/Utils.h header to make them available 
  to other passes.
- In `mlir::generateUnrolledLoop()`, add also an optional 
  `IRMapping *clonedToSrcOpsMap` argument to map the new cloned 
  operations to their original ones.
  In the function body, change the default `AnnotateFn` type to 
  `static const` to silence potential warnings about dangling references 
   when a function_ref is assigned  to a variable with automatic storage.

Signed-off-by: Fabrizio Indirli <Fabrizio.Indirli@arm.com>

Adding canonicalization pattern in case execute_region op has yieldOps
which operands are from outside the execute_region, then it simplifies
the op to return just internal values. The pattern is applied only in
case all yieldOps within execute_region_op have same operands

---------

Co-authored-by: Mehdi Amini <joker.eph@gmail.com>

Currently when peeling the first iteration, any mentioning of UB within the loop body is replaced with the new UB in the peeled out first iteration. This introduces a bug in the following scenario: Operations inside of the loop that intentionally use the original UB are incorrectly updated.

The callers of public or extern functions are unknown, so their function
signatures cannot be changed.

Reverts llvm/llvm-project#150278

Multiple post-merge comment remained undressed, and some more
fundamental issues were also reported in #159165