unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Andy Wingo <wingo@igalia.com>
Cc: 39573-done@debbugs.gnu.org
Subject: bug#39573: [3.0.0] Compiler fails to optimize out side-effect-free expression
Date: Thu, 13 Feb 2020 12:35:59 +0100	[thread overview]
Message-ID: <87imka90tc.fsf@gnu.org> (raw)
In-Reply-To: <87lfp7am56.fsf@igalia.com> (Andy Wingo's message of "Wed, 12 Feb 2020 15:57:41 +0100")

Hi Andy,

Andy Wingo <wingo@igalia.com> skribis:

>> However, 3.0.0 keeps the computation of ‘i’:
>>
> [...]
>> L3:
>>   53    (instrument-loop 139)           
>>   55    (handle-interrupts)             
>>   56    (call-scm<-scm-uimm 5 5 1 3)                          at (unknown file):388:11
>>   58    (call-scm<-scm-uimm 3 3 1 34)                         at (unknown file):389:21
>>   60    (call-scm<-scm-scm 3 4 3 10)                          at (unknown file):389:11
>>   62    (=? 5 4)                                              at (unknown file):385:11
>>   63    (jne -10)                       ;; -> L3
>
> Hoo, we need to fix the disassembler to output something more sensible
> than this :P  IP 56 appears to be the 1-, 58 is the lsh/immediate, and
> 60 is the logior.

Oh, I hadn’t read that much into these lines.  :-)

>> I’m not sure where the optimization should be taking place.  Perhaps
>> it’s just a matter of amount-of-work threshold somewhere?
>
> It's not an amount-of-work, that's only in peval which does nothing to
> either of these (though it certainly could).
>
> I took a look.  I just pushed something to make (logior 0 INT) reduce to
> INT, but it doesn't remove the loop variable.

OK.

> Then I thought it was surely dead code elimination that just wasn't
> doing its thing.  The value is unused, so it must be that it thought
> that the `ash' was effectful.  That `ash' gets compiled to
> `lsh/immediate', which does indeed raise an exception if the operand
> isn't an int; but here we prove that it is.  The problem was a missing
> "type checker" implementation for lsh/immediate, a problem introduced in
> the refactored compilation of `ash'.  So, fixed in git now:
>
> L3:
>   45    (instrument-loop 135)           
>   47    (handle-interrupts)             
>   48    (call-scm<-scm-uimm 5 5 1 3)                          at (unknown file):4:12
>   50    (=? 5 4)                                              at (unknown file):3:12
>   51    (jne -6)                        ;; -> L3

Yay!  It’s nice to see how 7dc90a17e03045c7cd8894b14b027b845b68aa4f is
short and clear.

Thanks,
Ludo’.





  reply	other threads:[~2020-02-13 11:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 11:50 bug#39573: [3.0.0] Compiler fails to optimize out side-effect-free expression Ludovic Courtès
2020-02-12 14:57 ` Andy Wingo
2020-02-13 11:35   ` Ludovic Courtès [this message]
2020-02-13 15:11     ` Mikael Djurfeldt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87imka90tc.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=39573-done@debbugs.gnu.org \
    --cc=wingo@igalia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).