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.schonw...@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 <rrnew...@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.schonw...@gmail.com> wrote: >>> >>> nvm, githubs backup, i'll have a look! :) >>> >>> >>> On Sat, Aug 3, 2013 at 9:05 PM, Carter Schonwald < >>> carter.schonw...@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 <rrnew...@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 <rrnew...@gmail.com> wrote: >>> >>> On Sun, Jul 21, 2013 at 3:32 AM, Carter Schonwald < >>> carter.schonw...@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 >> > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs