Proposal: provide cas and barriers symbols even without -threaded

[Ryan Newton]

Do you have a branch already lined up for your LLVM-atomics work?



On Sat, Aug 10, 2013 at 7:02 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> huh, did I suggest viewing it as a bug fix? my mistake! (a branch would
> make sense)
>
>
> On Sat, Aug 10, 2013 at 12:40 PM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> Well for new features like this (rather than bug fix), I'd prefer if I
>> could get commit access and at least push it to a branch.  I can create a
>> new trac ticket too.
>>
>>
>> On Saturday, August 3, 2013, Carter Schonwald wrote:
>>
>>> took a quick look,  awesome! this will make it MUCH MUCH easier for me
>>> to do my work. Thank you very much.
>>>
>>> off hand, to prevent patch confusion,
>>>  it naively seems like the nicest way to post the patches to trac is to
>>> post a *new ticket to trac* that links to the main one,
>>>  plus add a comment on the main ticket a link to the new ticket for the
>>> c/cmm based versions of the primops.
>>>
>>>  At least, given that theres likely going to be a bit of discussion on
>>> just your ticket perhaps, better to factor that into a related ticket to
>>> make it easier to keep track of that?
>>>
>>> (i'm also possibly over thinking this enormously, so i could be way off
>>> base)
>>>
>>>
>>>
>>> On Sat, Aug 3, 2013 at 9:31 PM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>> nvm, githubs backup, i'll have a look! :)
>>>
>>>
>>> On Sat, Aug 3, 2013 at 9:05 PM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>> awesome! (this will also make my work easier)
>>>
>>> ryan: github is down, could you put the branch on bitbucket or some such
>>> so I can have a lookseee/clone locally?
>>>
>>> thanks!
>>> -Carter
>>>
>>>
>>> On Sat, Aug 3, 2013 at 4:01 AM, Ryan Newton <rrnewton at gmail.com> wrote:
>>>
>>> Just to keep you all up to date...  I'm adding the primops in question
>>> and validating the individual commits before putting them here:
>>>
>>>     https://github.com/rrnewton/ghc/commits/atomicPrimOps
>>>
>>> The basic idea for using these extensions is:
>>>
>>>    - the atomic-primops library will work in 7.6 or 7.7+.  It will use
>>>    ifdefs to decide whether to use its own primops or GHC-builtin
>>>    - future versions will simply get faster, as Carter replaces
>>>    out-of-line primops that *also* use C calls, with inline primops / LLVM
>>>    equivalents
>>>
>>> Shall I stick a patch on a ticket, or will someone volunteer to pull?
>>>  What's the protocol for requesting commit access anyway?  (By the way, can
>>> someone share the reason that pull-requests to the github ghc mirror are
>>> such a no-no?  They seem no worse than a patch in an email which the big warning
>>> sign <https://github.com/ghc/ghc> recommends.)
>>>
>>> Best,
>>>   -Ryan
>>>
>>> P.S. FYI, I'm periodically getting these:
>>>
>>>     0 caused framework failures
>>>     0 unexpected passes
>>>     1 unexpected failures
>>>
>>>      Unexpected failures:
>>>  perf/compiler  T1969 [stat not good enough] (normal)
>>>
>>> Can that just be because of running on a loaded machine?  How narrow are
>>> these windows?
>>>
>>>
>>> On Thu, Aug 1, 2013 at 12:32 PM, Ryan Newton <rrnewton at gmail.com> wrote:
>>>
>>> On Sun, Jul 21, 2013 at 3:32 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>> ok, could you add those comments (about additional operations to
>>> consider) to the ticket?
>>>
>>>
>>> Sure.  Just did that.
>>>
>>>
>>> relatedly: if we want these atomic ops to use the sequential analogues
>>> when we're not using the threaded run time system, does that mean
>>> we need to have a symbol / constant variable exposed in the RTS we link
>>> in, so that the inline code branches on a linktime constant value / symbol
>>> (something like "isThreadedRTS:: Bool", )  or some sort of analogue
>>> thereof?
>>>
>>>
>>> <
>>>
>>>
>>
>> --
>> Sent from Gmail Mobile
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130812/9597f932/attachment.htm>