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

[Peter Wang]

On Wed, 07 Dec 2022 11:51:20 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> 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).
> 

Yes, we just forgot to update int_emu when the semantics of << and >>
changed.

> > 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.

Understood.

Peter