unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





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