[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Mostly fix #1604

From: megane
Subject: Re: [Chicken-hackers] [PATCH] Mostly fix #1604
Date: Wed, 29 May 2019 12:25:38 +0300
User-agent: mu4e 1.0; emacs 25.1.1

Peter Bex <address@hidden> writes:

> On Wed, May 29, 2019 at 10:39:54AM +0300, megane wrote:
>> Consider the case (= a b c). If the C_and in the rewrite short-circuits
>> then 'c' is never evaluated, right?
> Ah, good observation.  That might be a problem.

It doesn't seem to be a problem currently, but might become an issue in
future if the optimizer gets smarter.

In the two argument case we can of course drop the lets!

>> Testing this indicates this is not an issue. Playing with gcc
>> optimization flags didn't drop the evaluation of the 'c' node either.
> I don't understand.  If you do (= 1 2 (error "hi")), it should raise
> the exception.  Of course for "error" specifically it's not an issue
> because "error" is not inlineable.

As I said it's not an issue, c always gets evaluated.

Here's one test that fails to show the issue:

  (import (chicken process-context) (chicken type))

  (: foo (fixnum -> fixnum))
  (define (foo n)
    (let ([v (string->number (list-ref (command-line-arguments) n))])
      (print n ": " v)
  C_word bar () { printf ("bar\n"); return C_fix (42); }

  (print (= (foo 0) (foo 1) (##core#inline "bar")))

The (##core#inline "bar") call gets its own temporary variable so it's
always evaluated, i.e. it's not inlined.

>> I also tested that the lets in the rewrite can be dropped altogether.
>> The arguments are bound to variables by the CPS conversion anyway.
>> There's no duplicate evaluation.
> How do you enforce that?  If there's an inlineable call it doesn't
> need to be bound to a variable.  Something like (set! a 1) would be
> inlineable.

I couldn't find something that has side-effects and is inlineable. (set!
a 1) also gets its own temporary variable. Everything seems to get
temporary variables.

>> If you look at the output of -debug 5 you see that the next optimization
>> iteration drops the 'let's generated by the rewrite.
> You mean with the change you made?

I meant with your patch.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]