On 1/17/07, Mircea Namolaru <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Richard Kenner) wrote on 17/01/2007 18:04:20:
> > First, it seems to me that in your case:
> >
> > (1) a = a | 1 /* a |= 1 */
> > (2) a = a | 1 /* a |= 1 */
> >
> > the expressions "a | 1" in (1) and (2) are different as the "a"
> > is not the same. So there is nothing to do for CSE.
>
> It's not a CSE issue, but after (1), you know that the low-order bit of
> "a" is a one, so that (2) is a no-op. Note that the similar
> a &= ~1;
> a &= ~1;
>
> we do catch in combine.
>
> It could also be caught by converting
>
> a = ((a | 1) | 1);
>
> into
>
> a = (a | (1 | 1));
>
Yes, you are right if (1) and (2) are in the same basic block.
But the initial example that started this thread looks like:
a |= 1;
if (*x) ...
a }= 1;
so (1) and (2) are in two separate basic blocks. I think that
in this case combine doesn't work.
combine wouldn't work in this case because its going to work only
within a basic block . IIRC in this case the CSE pass in 3.4.x was
removing (2) and retaining just (1) . Alas , don't have logs handy
now. Also this is removed for the case of integers by the CSE pass
IIRC . The problem arises only for the type being a char or a short.
~ramana
Mircea
--
Ramana Radhakrishnan
