[m-rev.] for review: extend constant propagation to sized integer types

[Peter Wang]

On Wed, 19 Apr 2023 20:57:20 +1000 Julien Fischer <jfischer at opturion.com> wrote:
> On Wed, 19 Apr 2023 at 14:27, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> >
> >
> > 2023-04-19 14:12 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
> > >>     Add predicates to emulate the logical operations AND, OR, XOR and NOT.
> > >>     With these, the original code (in const_prop.m) did *not* work by
> > >>     doing the operation on arbitrary precision integers. I am not sure
> > >>     if that was a deliberate decision to avoid integer.m's logical operations,
> > >>     which I expect would not have been tested nearly as thoroughly
> > >>     as the arithmetic ops.
> > >
> > > I'm fairly certain that they haven't been as extensively tested, but I don't
> > > think that's the reason. (Note that the initial version of const_prop.m was in
> > > 1997, which predates the addition of bitwise operations to the integer module
> > > by two years.)
> >
> > Yes, but I didn't know whether *not updating the code in const_prop.m when
> > those ops were added to integer.m* was a deliberate decision or not.
> 
> Hopefully Peter remembers since it appears he switched const_prop.m
> over to use int_emu.m.

It would not have been because I was unsure about the reliability of
integer.m.

We didn't have the new unsigned or non-word-sized integer types then,
so it's possible I thought bitwise complement didn't need changing.
Actually, I'm having trouble coming up with a situation where the
compile time evaluation of bitwise complement on ints would be an issue
(sign extension would be done by the downstream compiler).

Peter