On Tue, Nov 29, 2011 at 08:09:31AM -0800, Richard Henderson wrote:
> Tight loops like this should use the weak compare-exchange so that we don't
> get two nested loops without need.
Done.
> I do think we need more commentary here so that next month I can still follow
> it.
Added this in gomp_s
On 11/29/2011 08:09 AM, Richard Henderson wrote:
>> +static inline bool
>> +likely_compare_exchange (int *ptr, int *expected, int val, bool weak,
>> + enum memmodel succ, enum memmodel fail)
>> {
>> + return __builtin_expect (__atomic_compare_exchange_n (ptr, expected, val,
>>
On 11/29/2011 04:49 AM, Alan Modra wrote:
> Since there were a number of changes requested, and some confusion
> over what was happening in this code, it might be better if I post
> a new patch and we start over. In this patch I'm still using the MSB
> for the wait flag, and count in the low 31 bi
Since there were a number of changes requested, and some confusion
over what was happening in this code, it might be better if I post
a new patch and we start over. In this patch I'm still using the MSB
for the wait flag, and count in the low 31 bits, as that way is
slightly more efficient on powe
On Mon, Nov 28, 2011 at 04:00:10PM -0800, Richard Henderson wrote:
> On 11/27/2011 02:53 PM, Alan Modra wrote:
> > +enum memmodel
> > +{
> > + MEMMODEL_RELAXED = 0,
> > + MEMMODEL_CONSUME = 1,
> > + MEMMODEL_ACQUIRE = 2,
> > + MEMMODEL_RELEASE = 3,
> > + MEMMODEL_ACQ_REL = 4,
> > + MEMMODEL_S
On 11/28/2011 03:05 PM, Richard Henderson wrote:
> On 11/28/2011 02:16 PM, Alan Modra wrote:
>> Hmm, I suppose you could argue that powerpc and others ought to not
>> generate those three extra instructions when using the return value.
>> I'll see about fixing powerpc.
>
> However, we can do bette
On 11/27/2011 02:53 PM, Alan Modra wrote:
> +enum memmodel
> +{
> + MEMMODEL_RELAXED = 0,
> + MEMMODEL_CONSUME = 1,
> + MEMMODEL_ACQUIRE = 2,
> + MEMMODEL_RELEASE = 3,
> + MEMMODEL_ACQ_REL = 4,
> + MEMMODEL_SEQ_CST = 5,
> + MEMMODEL_LAST = 6
> +};
This should probably go to libgomp.h.
> /
On 11/28/2011 02:16 PM, Alan Modra wrote:
> Hmm, I suppose you could argue that powerpc and others ought to not
> generate those three extra instructions when using the return value.
> I'll see about fixing powerpc.
True. For weak, the value *should* always be used (otherwise the user program
is
On Mon, Nov 28, 2011 at 05:23:37PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 28, 2011 at 09:23:43AM +1030, Alan Modra wrote:
> > + int count = *sem;
> > +
> > + while ((count & 0x7fff) != 0)
> > +{
> > + int oldval = count;
> > + __atomic_compare_exchange_4 (sem, &oldval, count
On Mon, Nov 28, 2011 at 09:23:43AM +1030, Alan Modra wrote:
> + int count = *sem;
> +
> + while ((count & 0x7fff) != 0)
> +{
> + int oldval = count;
> + __atomic_compare_exchange_4 (sem, &oldval, count - 1,
> +false, MEMMODEL_ACQUIRE, MEMMODEL_REL
On Fri, Nov 25, 2011 at 08:38:39AM +0100, Jakub Jelinek wrote:
> Furthermore, I'd prefer if the patch could be split into smaller parts,
> e.g. for bisecting purposes. One patch would do the mutex changes
> to use new atomics, remove extra mutex.h headers and start using 0/1/-1
> instead of 0/1/2.
On Fri, Nov 25, 2011 at 08:38:39AM +0100, Jakub Jelinek wrote:
> My preference would be to avoid the abstraction changes though, both
> because it is additional clutter in the changeset and because omp_lock
> and nested lock are part of public ABIs, so if struct is layed out
> differently on some w
On Fri, Nov 25, 2011 at 10:33:28AM +1030, Alan Modra wrote:
> This fixes PR51249, a failure caused by insufficient care in waking
> threads on sem_post. It's quite a tricky business to get right, but I
> believe this rewrite is now correct. I've also converted over lock.c,
> mutex.h and mutex.c t
This fixes PR51249, a failure caused by insufficient care in waking
threads on sem_post. It's quite a tricky business to get right, but I
believe this rewrite is now correct. I've also converted over lock.c,
mutex.h and mutex.c to use the new atomic builtins. This means no
target should need tar
14 matches
Mail list logo
