> This was caused (or perhaps abetted by) the representation of EQ
> as NE ^ 1. With the subsequent truncation and zero-extend, I
> think combine reached its insn limit of 3 before seeing everything
> it needed to see.
This can be 4 now, if you tweak the initial heuristic.
--
Eric Botcazou
Richard Henderson wrote:
> On 08/07/2012 10:02 AM, Ulrich Weigand wrote:
> > The following patch changes the builtin expander to pass a MEM oldval
> > as-is to the back-end expander, so that the back-end can move the
> > store to before the CC operation. With that patch I'm also seeing
> > all the
On 08/07/2012 10:02 AM, Ulrich Weigand wrote:
> The following patch changes the builtin expander to pass a MEM oldval
> as-is to the back-end expander, so that the back-end can move the
> store to before the CC operation. With that patch I'm also seeing
> all the IPMs disappear.
...
> What do you
Richard Henderson wrote:
> On 08/06/2012 11:34 AM, Ulrich Weigand wrote:
> > There is one particular inefficiency I have noticed. This code:
> >
> > if (!__atomic_compare_exchange_n (&v, &expected, max, 0 , 0, 0))
> > abort ();
> >
> > from atomic-compare-exchange-3.c gets compiled into:
>
On 08/06/2012 11:34 AM, Ulrich Weigand wrote:
> There is one particular inefficiency I have noticed. This code:
>
> if (!__atomic_compare_exchange_n (&v, &expected, max, 0 , 0, 0))
> abort ();
>
> from atomic-compare-exchange-3.c gets compiled into:
>
> l %r3,0(%r2)
>
