[m-rev.] for review: extend constant propagation to sized integer types
Julien Fischer
jfischer at opturion.com
Wed Apr 19 20:57:20 AEST 2023
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.
> >> ZZZ Does anyone know the history here?
> >
> > AND, OR XOR and NOT are never going to extend a value beyond what can be
> > represented by its type;
>
> The problem comes in defining what "its type" means when
> - the operand is word sized, and
> - the word sizes of the host and target machines differ.
>
> A bitwise negation *can* extend a value in that case, which is a bug
> that you fixed yourself. That fix (not applying const prop if the word sizes differ)
> will still work. I am concerned about integer.m's bitwise ops screwing up
> *before* restricting their results to the result type's number of bits.
>
> the original version of const_prop did not use
> > int_emu.m (which was added in 2015). The treatment of these bitwise operations
> > is what const_prop.m has always done.
>
> Yes, I know that is what const_prop has always done; that is why I continued
> that approach, just extending it to other types. What I meant by my question was:
> does anyone know the history of the bitwise ops in integer.m? Specifically, I would
> like to know whether they have been tested enough to use them here.
No, they haven't. The existing tests of the integer module
(hard_coded/integer_test)
are not particularly comprehensive, nor particularly systematic.
(Certainly, nothing
like what we have for other integer modules.). Until this is rectified
I think const_prop.m
should just use its current approach.
Julien.
More information about the reviews
mailing list