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
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
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:
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo