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

[megane]

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)
      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.