GNU bug report logs - #46847
28.0.50; [native-comp] assume pseudo-insns should be verified

Previous Next

Full log

Message #8 received at 46847 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 46847 <at> debbugs.gnu.org
Subject: Re: bug#46847: 28.0.50; [native-comp] assume pseudo-insns should be
 verified
Date: Mon, 01 Mar 2021 20:12:15 +0000

Pip Cet <pipcet <at> gmail.com> writes:

> This is a wishlist item for the native-comp branch, though I consider
> the feature in question to be so essential that its absence also
> qualifies as a bug.
>
> The native-comp branch is emitting assume pseudo-insns. Those come in
> various forms, but their interpretation is clear: they express
> conditions which are meant to hold at runtime, and which the compiler
> may use to optimize code.
>
> I would like to add an optional compiler pass which asserts that the
> conditions are actually true at runtime. This is a basic safeguard
> that any assume() mechanism should have, and it's perfectly equivalent
> to the way eassume() becomes eassert() in debug builds of Emacs.
>
> Unfortunately, it turns out that while adding the compiler pass is
> easy, there are many failures because the assume pseudo-insns emitted
> at present are inconsistent or plain wrong. Some of these wrong
> assumes result in reproducible Lisp-to-native-code bugs today; others
> will not; for still others, we're not sure.

I think the issue might be that how assumes works has been
miss-understood here.

Assumes are working after SSA rename in the world of mvar ids, in
contrast we render code based on slot numbers.  Rendering assertions
based on assumes using the slot numbers (IIUC that's what your patch
did) certainly leads to inconsistencies, but that's a fundamental
miss-interpretation of how assumes are working.  This is probably also
why you often suggests assumes are inconsistent.

Anyway, for the reasons above rendering 1:1 assumes into run-time checks
is not easily possible.

OTOH a possible way, and that's what I want to do, would be to verify
just before each (non pseudo) insn actually rendered that the slots in
use there are consistent with the prediction.

One could even control that with a parameter and have a mode where we
just inject asserts on return insns not to bloat excessively the code.

Note: I'm not aware of any compiler emitting run-time checks to verify
its compile time predictions by why not.

I'll take this task as sounds like good verification/development cost
trade-off to me.  Will follow-up on this!

Thanks

  Andrea

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.