From: Andy Wingo <wingo@igalia.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: bug-Guile@gnu.org
Subject: bug#39573: [3.0.0] Compiler fails to optimize out side-effect-free expression
Date: Wed, 12 Feb 2020 15:57:41 +0100 [thread overview]
Message-ID: <87lfp7am56.fsf@igalia.com> (raw)
In-Reply-To: <87k14svxbf.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 12 Feb 2020 12:50:44 +0100")
On Wed 12 Feb 2020 12:50, Ludovic Courtès <ludo@gnu.org> writes:
> Hello!
>
> Consider this loop:
>
> (let loop ((n (expt 2 18))
> (i 1))
> (unless (zero? n)
> (loop (- n 1)
> (logior 0 (ash i 1)))))
>
> Guile 2.2 strips away the computation of ‘i’ (it cannot throw, has no
> side effects, and the result is unused):
>
[...]
> L1:
> 27 (handle-interrupts) at (unknown file):21:11
> 28 (sub/immediate 4 4 1)
> 29 (br-if-u64-=-scm 3 4 #t -2) ;; -> L1 at (unknown file):18:11
Like specifically, it removes the logior call.
> 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.
> 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.
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
Cheers,
Andy
next prev parent reply other threads:[~2020-02-12 14:57 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 [this message]
2020-02-13 11:35 ` Ludovic Courtès
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=87lfp7am56.fsf@igalia.com \
--to=wingo@igalia.com \
--cc=bug-Guile@gnu.org \
--cc=ludo@gnu.org \
/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).