On 4/28/23 10:44, Patrick O'Neill wrote:
On 4/28/23 09:29, Palmer Dabbelt wrote:
On Fri, 28 Apr 2023 09:14:00 PDT (-0700), jeffreya...@gmail.com wrote:
On 4/27/23 10:22, Patrick O'Neill wrote:
...
LLVM mapping notes
--------
LLVM emits corresponding fences for atomic_signal_fence instructions.
This seems to be an oversight since AFAIK atomic_signal_fence acts
as a
compiler directive. GCC does not emit any fences for
atomic_signal_fence
instructions.
This starts to touch on a larger concern. Specifically I'd really like
the two compilers to be compatible in terms of the code they generate
for the various atomics.
What I worry about is code being written (by design or accident)
that is
dependent on the particular behavior of one compiler and then if that
code gets built with the other compiler, and we end up different
behavior. Worse yet, if/when this happens, it's likely to be tough to
expose, reproduce & debug.
Agreed.
I'll open an issue with LLVM and see what they have to say about this
particular behavior. Ideally we'd have perfectly compatible compilers
(for atomic ops) by the end of this :)
AFAICT GCC hasn't ever been emitting fences for these instructions.
(& This behavior isn't touched by the patchset).
I re-ran the set of tests I was using and couldn't replicate LLVM's
behavior that was noted here. I think I mixed had up atomic_thread_fence
with atomic_signal_fence at some point.
That was the only difference I could find during my testing of this
patchset (other than the strengthened SEQ_CST store), so I think
GCC/LLVM atomics will be fully compatible once this patchset is applied.
