Re: Better calling conventions for strict functions (bang patterns)?

Thanks Simon for linking that issue! Does the patch linked there already cover what you suggested in your last mail? I think no, it's a more limited change, but I'm having

Re: Better calling conventions for strict functions (bang patterns)?

On 02/11/2015 06:37, Ryan Newton wrote: Thanks Simon for linking that issue! Does the patch linked there already cover what you suggested in your last mail? I think no,

Re: Better calling conventions for strict functions (bang patterns)?

Sorry, forgot to respond to your other point: On 02/11/2015 06:37, Ryan Newton wrote: Thanks Simon for linking that issue! Does the patch linked there already cover what

Re: Better calling conventions for strict functions (bang patterns)?

Yes, I think we can probably do a better job of compiling case expressions. The current compilation strategy optimises for code size, but at the expense of performance in the fast path. We can tweak this tradeoff, perhaps under the control of a flag. Ideally the sequence should start by

RE: Better calling conventions for strict functions (bang patterns)?

sion, etc) I’m happy to advise. Simon From: Ryan Newton [mailto:rrnew...@gmail.com] Sent: 23 October 2015 19:31 To: Simon Peyton Jones Cc: ghc-devs@haskell.org; Ömer Sinan Ağacan; Ryan Scott; Chao-Hong Chen; Johan Tibell Subject: Re: Better calling conventions for strict functions (bang patt

Re: [DISARMED] RE: Better calling conventions for strict functions (bang patterns)?

Simon, I really enjoyed reading this paper... I was wondering if you could comment on the implementation of Strict Core? Was it ever implemented in GHC (even as a proof-of-concept)? If not, was it just due to a lack of time or some fundamental limitation or problem discovered after the paper? If

Re: Better calling conventions for strict functions (bang patterns)?

Doesn't modern hardware have pretty good branch prediction? In which case the order of the branches may not matter unless it's a long chain of calls? Vs say an inner loop that hasn't been inlined? Either way, I'd love be stay in the loop on this topic, for work I'm building a strongly normalizing

RE: Better calling conventions for strict functions (bang patterns)?

It’s absolutely the case that bang patterns etc tell the caller what to do, but the function CANNOT ASSUME that its argument is evaluated. Reason: higher order functions. I think that the way to allow functions that can assume their arg is evaluated is through types: see Type are calling

Re: Better calling conventions for strict functions (bang patterns)?

> > >1. Small tweaks: The CMM code above seems to be *betting* than the >thunk is unevaluated, because it does the stack check and stack write >*before* the predicate test that checks if the thunk is evaluated (if >(R1 & 7 != 0) goto c3aO; else goto c3aP;). With a bang-pattern >

Re: Better calling conventions for strict functions (bang patterns)?

Ah, yes, so just to give a concrete example in this thread, if we take the `foo` function above and say `map foo ls`, we may well get unevaluated arguments to foo. (And this is almost precisely the same as the first example that Strict-Core paper!) Thanks for the paper reference. I read it and