From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Salter <msalter(at)redhat(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Raiskup <praiskup(at)redhat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Add support for TAS/S_UNLOCK for aarch64 |
Date: | 2013-06-04 18:27:59 |
Message-ID: | 29866.1370370479@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Salter <msalter(at)redhat(dot)com> writes:
> On Tue, 2013-06-04 at 13:40 -0400, Tom Lane wrote:
>> We got no response to the question of whether it couldn't be merged with
>> the existing ARM32 code block. I'd prefer not to have essentially
>> duplicate sections in s_lock.h if it's not necessary.
> Of course it could be. I don't think it should be. Aarch64 is a
> completely new architecture with faint resemblance to 32bit arm.
OK, fair enough.
> I went
> back and read the previous thread concerning the problems with builtin
> gcc atomics with certain tool/hardware combinations. Would it be okay to
> add a default implementation based on gcc builtins to be used if no
> arch-specific definitions exist? If so, I could work up a patch for
> review.
We had pretty much rejected that concept in the previous discussion,
I thought. In the first place, there is no good reason to assume
that somebody on a nonstandard platform is using gcc, and in the second,
our review of the available info suggested that the implementation
quality of gcc's builtins is ... um ... variable. Blindly falling back
to that on a platform we haven't tested does not seem very safe.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2013-06-04 18:50:44 | RFC: ExecNodeExtender |
Previous Message | Josh Berkus | 2013-06-04 18:23:24 | Re: Configurable location for extension .control files |