From: Pip Cet <pipcet@gmail.com>
To: Andrea Corallo <akrl@sdf.org>
Cc: 46670@debbugs.gnu.org, Mauricio Collares <mauricio@collares.org>
Subject: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode
Date: Tue, 23 Feb 2021 09:07:26 +0000 [thread overview]
Message-ID: <CAOqdjBeZZs7GTLDj8MH6OXhhTH9LujnOABuCf7uvVsV4dPNRbA@mail.gmail.com> (raw)
In-Reply-To: <xjfblccl5d6.fsf@sdf.org>
On Mon, Feb 22, 2021 at 11:16 AM Andrea Corallo <akrl@sdf.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
> >> Yes but in this case (and probably others) we *have* to emit this
> >> assumption.
> >
> > Why? Are you saying the compiler requires (assume ...) insns for
> > correctness? If it does, I'm afraid that's a serious issue.
>
> It requires that assume if we want to infer precisely here. If we
> give-up emitting this assume it will just works perfectly but we'll miss
> to predict the return value as we should.
Emitting an assumption about a dead variable only makes sense if the
dead variable matches a live one. And in that case, we can just emit
the assumption about the live variable to begin with.
> > Again, that does seem very complicated, and if it improves
> > optimization we could probably improve it much more by modifying the
> > byte compiler to pop arguments in the caller rather than the callee.
>
> To me this sounds considerably more invasive, probably is because I'm
> much more used to work with the native compiler code that with the byte
> compiler one :)
That is a little more invasive, but it's where you're going if you
make the major change of allocating your own stack slots rather than
letting the byte compiler do it.
> I like the idea of the native compiler patch being less invasive as
> possible, this was the line I tried to follow and I think so far it
> paid. I guess a number of readers would'd agree with this kind of
> approach to begin with.
I agree with it! That's why "leave slot allocation to the byte
compiler" is something I don't want you to throw away unnecessarily,
because it's a great simplifying assumption.
> I think I should be able to work it out as discussed in one two evenings
> and it might be useful for other cases in the future too, so it does not
> sound as a big deal to me.
It does to me, I must say. There's nothing special about comparisons:
you're turning a = a OP b two-operand code into c = a OP b
three-operand code. Your code won't be as good as genuine
three-operand code, and it won't be as simple as two-operand code.
> >> > In fact, all we need to do is tell comp-cond-cstrs-target-mvar to
> >> > return nil more often, isn't it?
> >>
> >> Nope, the target mvar identified is the correct one, we just have ATM no
> >> way to reference it reliably into the assume.
> >
> > We don't have to, let's just not emit an assume about a variable that
> > we just introduced and that's never read?
>
> We disagree :)
We can disagree about the "let's" part (and should, of course), but we
should agree about the "we don't have to" part, because that's a
matter of fact, not opinion.
> As the byte compiler does not care about propagating types and values it
> can just clobber the variable, here we aim for more so we need it to
> keep it live till the assume.
If we decide the variable needs to be kept live, the byte compiler
should keep it live, not us.
next prev parent reply other threads:[~2021-02-23 9:07 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-21 0:12 bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode Mauricio Collares
2021-02-21 11:51 ` Pip Cet
2021-02-21 11:56 ` Pip Cet
2021-02-21 21:03 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-21 22:46 ` Pip Cet
2021-02-22 9:37 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-22 10:04 ` Pip Cet
2021-02-22 10:25 ` Pip Cet
2021-02-22 11:23 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-22 12:11 ` Pip Cet
2021-02-22 13:12 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-23 7:59 ` Pip Cet
2021-02-23 9:04 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-23 23:26 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-24 2:10 ` Mauricio Collares
2021-02-24 8:22 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-23 19:09 ` Pip Cet
2021-02-23 23:36 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-24 4:31 ` Pip Cet
2021-02-24 9:04 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-24 9:28 ` Pip Cet
2021-02-24 9:42 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-24 9:46 ` Pip Cet
2021-02-24 10:06 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-25 12:41 ` Pip Cet
2021-02-25 14:58 ` Eli Zaretskii
2021-02-25 15:14 ` Pip Cet
2021-02-25 15:31 ` Eli Zaretskii
2021-02-25 16:56 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-25 20:59 ` Pip Cet
2021-02-26 19:33 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-26 20:30 ` Pip Cet
2021-02-26 20:44 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-26 20:11 ` Eli Zaretskii
2021-02-26 20:32 ` Pip Cet
2021-02-27 5:06 ` Pip Cet
2021-02-27 7:49 ` Eli Zaretskii
2021-02-27 9:39 ` Pip Cet
2021-02-27 10:24 ` Eli Zaretskii
2021-02-27 12:39 ` Pip Cet
2021-02-27 13:30 ` Eli Zaretskii
2021-02-27 17:15 ` Pip Cet
2021-02-27 18:40 ` Eli Zaretskii
2021-02-28 8:14 ` Pip Cet
2021-03-01 5:24 ` Richard Stallman
2021-03-01 6:40 ` Pip Cet
2021-02-22 11:16 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-23 9:07 ` Pip Cet [this message]
2021-02-23 22:55 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-24 7:00 ` Pip Cet
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/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOqdjBeZZs7GTLDj8MH6OXhhTH9LujnOABuCf7uvVsV4dPNRbA@mail.gmail.com \
--to=pipcet@gmail.com \
--cc=46670@debbugs.gnu.org \
--cc=akrl@sdf.org \
--cc=mauricio@collares.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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).