Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CALCETrWaWTupSp6V=XXhvExtFdS6ewx_0A7hiGfStqpeuqZn8g@mail.gmail.com>
 <20181215225009.GB23599@brightrain.aerifal.cx> <alpine.LFD.2.21.1812160054300.11202@eddie.linux-mips.org>
 <20181216023259.GE23599@brightrain.aerifal.cx> <alpine.LFD.2.21.1812160319120.11202@eddie.linux-mips.org>
 <20181216181336.GG23599@brightrain.aerifal.cx>
In-Reply-To: <20181216181336.GG23599@brightrain.aerifal.cx>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Sun, 16 Dec 2018 10:59:19 -0800
Message-ID: <CALCETrXBfQ-EnOD3OjQh_BaiFyvULtmrMHoX0nv+=yrp6uHzgQ@mail.gmail.com>
Subject: Re: Fixing MIPS delay slot emulation weakness?
To:     Rich Felker <dalias@libc.org>
Cc:     "Maciej W. Rozycki" <macro@linux-mips.org>,
        Andy Lutomirski <luto@kernel.org>,
        Linux MIPS Mailing List <linux-mips@linux-mips.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Paul Burton <paul.burton@imgtec.com>,
        David Daney <david.daney@cavium.com>,
        Ralf Baechle <ralf@linux-mips.org>,
        Paul Burton <paul.burton@mips.com>,
        James Hogan <jhogan@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, Dec 16, 2018 at 10:13 AM Rich Felker <dalias@libc.org> wrote:
>
> On Sun, Dec 16, 2018 at 01:50:13PM +0000, Maciej W. Rozycki wrote:
> > On Sat, 15 Dec 2018, Rich Felker wrote:
> >
> >
> >  It doesn't help that information about that is scattered across many
> > documents.  You can check for the NODS flag in the opcodes library from
> > binutils though, which is almost 100% accurate, except for the SYNC
> > instructions, for semantic reasons (i.e. they are allowed, but we don't
> > want GAS to reorder them).  Most of the disallowed stuff is in the
> > microMIPS instruction set, due to encodings that execute as hardware
> > macros.
>
> I think it suffices to emulate what compilers generate in delay slots,
> which should be fairly minimal and stable. At the very least we could
> enumerate everything GCC and LLVM already emit there, and get them to
> upstream a policy of not adding new insns as fpu-delay-slot-allowed.
> If someone is writing asm by hand to do ridiculous things in the delay
> slot with random ISA extensions, they shouldn't expect it to work.
>

I feel like I have to ask: the real thing preventing emulation is that
new nonstandard instructions might get used in FPU delay slots on
non-FPU-supporting hardware?  This seems utterly nuts.  If you're
using custom ISA extensions, why on Earth are you also using emulated
floating point instructions?  You're targetting a specific known CPU
if you do this, so you should use only instructions that actually work
on that CPU.