chore(ssa): Simplify shl/shr identity operations

[vezenovm]

Description

Problem*

Resolves something I noticed while reviewing #9585

Summary*

Shifting by an lhs by zero will always result in the provided lhs.
The same is true for when the lhs is zero. Shifting zeroes will simply produce another number of zeroes.

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[TomAFrench]

@vezenovm Doesn't this allow you to shift a zero value by greater than the size of the type without an error?

[TomAFrench]

We should maintain this as an error rather than optimizing it out.

[vezenovm]

@vezenovm Doesn't this allow you to shift a zero value by greater than the size of the type without an error?

I thought it may be safe as zero shifted by any amount should still be zero. But if we would like to maintain this as an error I can remove the lhs_is_zero simplification.

[asterite]

We should maintain this as an error rather than optimizing it out.

I thought the same thing. But I checked with Rust and in debug mode it overflows and in release mode it doesn't so I wasn't sure, but shifting zero is unlikely to happen to maybe it's fine to error in that case.

[aakoshh]

but shifting zero is unlikely to happen

Fuzzer says: "Hold my🍺"

[TomAFrench]

I thought it may be safe as zero shifted by any amount should still be zero. But if we would like to maintain this as an error I can remove the lhs_is_zero simplification.

I don't see it as a safety thing but I think that if we say that performing a bitshift larger than the type's size results in an error then we shouldn't allow this on certain values. 1u32 >> 32 and 0u32 >> 32 are both "guaranteed to be zero" but now we error on one and not the other.