On Fri, Aug 17, 2018 at 07:46:22PM +0100, Ramsay Jones wrote:
>
>
> On 16/08/18 23:12, Luc Van Oostenryck wrote:
> > There is a potential problem when the second side of the OR
>
> second side? Do you mean right-hand side (RHS)?
Yes and no.
I don't know how to express this simply.
Maybe "the second call to simplify_mask_or_and()" or
"when trying to simplify with the role of the OR operands swapped".
Inside simplify_mask_or(), the first call to simplify_mask_or_and()
try to match AND(OR(AND(x, M'), b), M) and depending on the value
of M & M', either AND(x, M') is simplified or b is simplified.
The second call to simplify_mask_or_and() do the same but the
other order of the OR arguments: AND(OR(a, AND(y, M')), M).
This second call had a few problems (because in some places, it
made the assumption that the AND(_, M') was always the LHS and that
the other operand was the RHS, which is true in the first call
but false in the second).
> > +++ b/validation/optim/and-or-crash.c
> > @@ -0,0 +1,5 @@
> > +static int a(int b, unsigned c) { (c << 1 | b & 1 << 1) >> 1; }
>
> Is the mix of signed and unsigned int significant?
>
> It caused me to pause and try to remember my 'usual arithmetic
> conversions'. If I have remembered correctly, this seems to
> be equivalent to (int)(((unsigned int) | (int)) >> 1), leading to
> (int)((unsigned int) >> 1)), then (int)(unsigned int), finally (int).
>
> Hmm, so no. :-D
Indeed it's not very clear.
The 2 (signed) ints could be changed to unsigned but not the opposite.
What matters here is that a LSR is generated, not an ASR.
Having c as unsigned is enough for the whole expression to be
unsigned and thus to avoid the ASR.
I'll change it to use 'unsigned int' everywhere, it will be clearer
[but this is not a testcase showing a simplification, but automatically
generated code that at some moment during development made sparse crash].
Thanks for noticing this.
-- Luc
