Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-08-06 Thread Ulrich Weigand
Richard Henderson wrote: While the first set of changes looks good to me, I don't understand those: > @@ -4728,7 +4733,12 @@ init_alignment_context (struct alignment_context *ac, > rtx mem, >ac->aligned = (MEM_ALIGN (mem) >= GET_MODE_BITSIZE (SImode)); > >if (ac->aligned) > -ac->m

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-08-03 Thread Ulrich Weigand
I wrote: > Just a quick heads-up that something still must be broken; > I get extra test suite failures: > > FAIL: gcc.dg/atomic-compare-exchange-1.c execution test > FAIL: gcc.dg/atomic-compare-exchange-2.c execution test > FAIL: gcc.dg/atomic-compare-exchange-3.c execution test > WARNING: progra

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-08-03 Thread Ulrich Weigand
Richard Henderson wrote: > Please try this as a followup to the previous two patches. > That should clean up the mistake with the insv change. Just a quick heads-up that something still must be broken; I get extra test suite failures: FAIL: gcc.dg/atomic-compare-exchange-1.c execution test FAIL:

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-08-01 Thread Richard Henderson
Please try this as a followup to the previous two patches. That should clean up the mistake with the insv change. r~ commit 6b07a31943bcbca2a4f6fae707cf3d7ae283d4dc Author: Richard Henderson Date: Wed Aug 1 16:10:37 2012 -0700 fixup insv diff --git a/gcc/config/s390/s390.c b/gcc/config/s

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-08-01 Thread Richard Henderson
On 2012-08-01 10:14, Richard Guenther wrote: > If you said > > p_s->y = 0; > > then we can exploit the fact that you dereference p_s and derive > bigger alignment. But I don't see how we can massage the > builtin to preserve such form. Well, put in a memory reference > in the argument, __buil

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-08-01 Thread Richard Guenther
On Wed, 1 Aug 2012, Richard Henderson wrote: > On 08/01/2012 01:40 AM, Richard Guenther wrote: > > I see. So your issue is that you don't get the knowledge > > that the address is even more aligned than required by the > > builtin. > > Yes. Very helpful for quite a few targets that only have wo

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-08-01 Thread Richard Henderson
On 08/01/2012 01:40 AM, Richard Guenther wrote: > I see. So your issue is that you don't get the knowledge > that the address is even more aligned than required by the > builtin. Yes. Very helpful for quite a few targets that only have word-sized atomic operations, and we emulate char/short via

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-08-01 Thread Richard Guenther
On Tue, 31 Jul 2012, Richard Henderson wrote: > On 2012-07-31 02:09, Richard Guenther wrote: > > What do we expect __builtin_compare_exchange to do for > > unaligned inputs? > > At the moment we expect it to SIGBUS, as a rule. > > We'd *like* to defer to the library routine for unaligned, > but

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-07-31 Thread Richard Henderson
On 2012-07-31 11:17, Ulrich Weigand wrote: > This doesn't look correct: > + /* Emit a strict_low_part pattern if possible. */ > + if (bitpos == 0 && GET_MODE_BITSIZE (smode) == bitsize) > > With bitpos == 0 we need to insert into the *high* part, not > the low part on a big-endian platf

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-07-31 Thread Ulrich Weigand
Richard Henderson wrote: > I've had a go at generating better code in the HQImode CAS > loop for aligned memory, but I don't know that I'd call it > the most efficient thing ever. Thanks for having a look at this! > (3) Support for IC, and ICM via the insv pattern is lacking. > I've adde

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-07-31 Thread Richard Henderson
On 2012-07-31 02:09, Richard Guenther wrote: > What do we expect __builtin_compare_exchange to do for > unaligned inputs? At the moment we expect it to SIGBUS, as a rule. We'd *like* to defer to the library routine for unaligned, but we don't do that yet. Too bad about not being able to query ad

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-07-31 Thread Andrew MacLeod
On 07/31/2012 05:09 AM, Richard Guenther wrote: On Thus, the bad news is that it's hard for the middle-end to recover alignment of a memory access that is represented as a builtin function call that takes addresses as parameters (which also makes them address-taken and thus possibly aliased). Did

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

2012-07-31 Thread Richard Guenther
On Mon, 30 Jul 2012, Richard Henderson wrote: > The atomic_load/storedi_1 patterns are fixed to use LM, STM. > > I've had a go at generating better code in the HQImode CAS > loop for aligned memory, but I don't know that I'd call it > the most efficient thing ever. Some of this is due to > defi

[PATCH 0/2] Convert s390 to atomic optabs, v2

2012-07-30 Thread Richard Henderson
The atomic_load/storedi_1 patterns are fixed to use LM, STM. I've had a go at generating better code in the HQImode CAS loop for aligned memory, but I don't know that I'd call it the most efficient thing ever. Some of this is due to deficiencies in other parts of the compiler (including the s390