On 6/16/14, 4:20 PM, Phoebe Buckheister wrote:
On Mon, 16 Jun 2014 15:36:00 -0600, Jonathan Roelofs wrote:
Thanks, I'll put it back. I had assumed that in those cases, clang
would just always generate inline atomics and let LLVM fix it up if
the actual hardware doesn't support it.
I agree with your first suspicions though... this chunk of code isn't
in exactly the right spot, and so isn't checking the right thing.
I'm totally confused about this now. Always enabling atomics on Windows
seems fine, if that'll only run on hardware that has atomic
instructions anyway. But if we forced atomics off for anything that
wasn't Linux, a BSD or Bitrig anyway, and then required the Arch
version to match - really, why check for the OS at all? If we're not
going to emit anything that would call into the OS ourselves, the check
seems unnecessarily restrictive. If we hard-enable inline atomics for
Linux and the others, we'll not emit libcalls for atomics on those at
all.
I really have no idea to fix this now. Could you clear up my
confusion?
The requirement that the OS be (Linux || FreeBSD || NetBSD || Bitrig) is only
there when we can't generate an instruction sequence to handle the atomic, and
therefore we have to rely on __sync_* (and therefore the kernel because of the
implementation of those builtins on those platforms) to handle it for us.
I'm not sure about the windows case.
So unless *I'm* really misunderstanding (which is quite possible :] ), the set
of checks (in pseudocode) should roughly be:
if ( windows ) return true;
else if ( arch >= v6 ) {
version = whatever;
} else if ( !linux && !freebsd && !netbsd && !bitrig ) {
return false;
}
if ( Profile == "M" && MaxAtomicInlineWidth) {
MaxAtomicPromoteWidth = 32;
MaxAtomicInlineWidth = 32;
}
return true;
Jon
--
Jon Roelofs
[email protected]
CodeSourcery / Mentor Embedded
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
