[m-rev.] for review: define <<u and >>u

[Zoltan Somogyi]

On Wed, 7 Dec 2022 11:02:19 +1100, Peter Wang <novalazy at gmail.com> wrote:
> I see. It's because int_emu still implements the old behaviour of
> int.(<<) and int.(>>) operations, which would succeed (not throw an
> exception) for a shift amount outside the range range [0, bits_per_int).

Right. But now, this code means that int_emu.m's static evaluation
of some << and >> operations can replace a runtime abort with the
compile-time creation of a nonsense answer.

I think it is best if for both << and >>, and their unsigned and/or
unchecked versions, we statically evaluate calls to them only if the
shift amounts are in bounds, for two reasons. First, arranging at
compile time to get the same result for out-of-bounds shift amounts
as at runtime is far from trivial, and second, there is no point in even
trying to optimize a situation that will blow up the program, either
immediately (for the checked shifts) or later (for the unchecked shifts).

> If you merged the predicates and renamed it to
> checked_or_unchecked_left_shift or something, that would be okay.
> I would keep them as separate predicates. My original intention
> was that each predicate in int_emu emulates the corresponding operation
> in int.m.

I get that. Its just for the reason given about, I can't think of any
situation in which we would want to compile-time-evaluate
the checked and unchecked versions of an operation differently.

Zoltan.