[m-rev.] for review: extend constant propagation to sized integer types
Zoltan Somogyi
zoltan.somogyi at runbox.com
Wed Apr 19 14:27:01 AEST 2023
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.
>> 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.
>> + % All of the {int,uint}{,8,16,32,64} modules define unary plus,
>> + % unary minus, and bitwise negation. The other procedures below
>> + % are defined only in int.m; this is checked by the predicates that
>> + % emulate them.
>
> None of the uint* modules provide unary plus and unary minus.
Thanks for catching that, and for the review. I will add a check for signed ints,
and update the comment.
Zoltan.
More information about the reviews
mailing list