<html>

  <head>

    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <br>

    <div class="moz-cite-prefix">On 3/18/2016 11:54 AM, JF Bastien

      wrote:<br>

    </div>

    <blockquote

cite="mid:CABdywOfL==0PoxHjsxg0KGFGy=OqaHebWajWaGa1yHSV4cTFKw@mail.gmail.com"

      type="cite">

      <blockquote class="gmail_quote" style="margin:0 0 0

        .8ex;border-left:1px #ccc solid;padding-left:1ex">Some

        architectures support byte granularity memory protection.

        Accessing unsolicited bytes can cause a trap on those

        architectures.<br>

        <br>

        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.</blockquote>

      <div><br>

      </div>

      <div>That all sounds like something the frontend has to decide on

        based on what the target is. </div>

    </blockquote>

    <br>

    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.<br>

    <br>

    <pre class="moz-signature" cols="72">-- 

Employee of Qualcomm Innovation Center, Inc.

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

</pre>

  </body>

</html>