On 3/18/2016 11:54 AM, JF Bastien wrote:
Some architectures support byte granularity memory protection.
Accessing unsolicited bytes can cause a trap on those architectures.
I think it makes sense for atomic<char> and Atomic<char> to get
turned into the 4 byte __atomic intrinsics. Those 4 byte __atomic
intrinsics can then get lowered to efficient inlined code. If
someone has a regular char, and they use the __atomic or __sync
intrinsics directly, I'm fine with that going to a lib call. The
lib call can then either use the global lock shard, or access
extra data, depending on what is reasonable for that platform.
That all sounds like something the frontend has to decide on based on
what the target is.
A lot of it is a frontend decision. What goes in the libcall feels an
awful lot like the 386 vs 486 example that I hear a lot. If I want one
binary that can run on both a 386 (very limited atomic support) and a
486 (a bit more atomic support), then I generate the binary such that it
has library calls to atomic routines. The library on the 386 uses the
global lock shard, and the library on the 486 uses native instructions.
The same kind of thing would apply for one byte atomics when only four
byte atomics have hardware support. The library call would use the lock
shard as the default. If the platform doesn't have byte granularity
memory protection a different, lockless implementation could be used
that loads the surrounding four bytes instead and does all the masking.
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
