This reverts commit 7ad2c6db54a0e77249f2edb3c589ccf4c930d455.
PR #183395 introduced the `exact` flag to `index_cast` and
`index_castui` and updated some canonicalization patterns.
These canonicalization patterns were found to be unsound. For example:
* `index_cast(index_cast(x)) -> x`
* where one first truncates and then widens x
the rewrite is unsound because information is lost on the first cast as
it **may** truncate the value of x, therefore losing information. The
`exact` flag was made to make this transformation sound. Its semantics
are that when the `exact` flag is present, then it is assumed that the
operand to index_cast does not lose information (i.e., fits perfectly in
the destination type).
In PR #183395, the canonicalization rule was rewritten such that would
only match where the inner index_cast had the `exact` flag set.
* `index_cast(index_cast(x, exact)) -> x`
* where source type and destination type are the same
A post-merge review
[highlighted](https://github.com/llvm/llvm-project/pull/183395#discussion_r2880422529)
that the pattern above also disallows the following correct pattern:
* `index_cast(index_cast(x)) -> x`
* when the first index widens and the second one truncates.
Unfortunately the semantics of `index` are such that its bitwidth is
target specific. Attempts were made in
https://github.com/llvm/llvm-project/pull/184631 to automatically add
annotations were possible but no agreement was reached on the best way
to do this. Adding to the disagreement are the following points:
* [there are other unsound patterns that assume index is
64](https://github.com/llvm/llvm-project/pull/184631/changes#r2885181291)
* [The semantics of index is
contested](https://discourse.llvm.org/t/index-type-and-assumption-about-bitwidth/88287)
This lead to the belief that a reversal and an RFC would be a good
approach to get some consensus from the community before proceeding
further.
f2cdf3f3b0