[GHC] #15719: Primitive atomic logical operations

[GHC]

#15719: Primitive atomic logical operations
-------------------------------------+-------------------------------------
           Reporter:  dfeuer         |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:  8.8.1
          Component:  Compiler       |           Version:  8.6.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 We offer fetch-and-and, fetch-and-or, etc., which are available as GCC
 intrinsics. Unfortunately, as far as I can tell those operations are
 ''not'' actually offered by x86_64. So I ''believe'' GCC must be
 implementing them using CAS loops on that (rather important) architecture.
 On the other hand, that instruction set does offer a plain atomic-and,
 atomic-or, etc., that do not fetch. In some cases, that may be sufficient.
 For example, I'm currently designing a potential replacement for the
 stable pointer system that uses a bitmap to represent a free list. Each
 deletion operation needs to update the bitmap (or) and then check whether
 a certain threshold number of entries are free (popcnt). One
 straightforward way to accomplish this with available instructions would
 be

 1. Atomic OR to mark an entry free
 2. Load the bitmap
 3. Perform the popcnt test

 Of course, it would be ''nice'' to have fetch-and-or here, but we don't
 actually need it--if a bunch of deletions happen concurrently, then at
 least one of them will see the popcnt over the threshold.

 Could we (and should we) offer non-fetching atomic operations implemented
 natively where they're available? One important question is of course
 whether we'd actually get better performance this way than using a CAS
 loop. I would conjecture that this is this case under contention, but I
 don't actually know.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15719>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler