From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46219)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1aTBqo-0007Th-Dr
	for qemu-devel@nongnu.org; Tue, 09 Feb 2016 12:13:23 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1aTBql-0007FV-17
	for qemu-devel@nongnu.org; Tue, 09 Feb 2016 12:13:18 -0500
Received: from mail-pf0-x236.google.com ([2607:f8b0:400e:c00::236]:33694)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1aTBqk-0007FB-Ph
	for qemu-devel@nongnu.org; Tue, 09 Feb 2016 12:13:14 -0500
Received: by mail-pf0-x236.google.com with SMTP id q63so26719703pfb.0
	for <qemu-devel@nongnu.org>; Tue, 09 Feb 2016 09:13:14 -0800 (PST)
Sender: Richard Henderson <rth7680@gmail.com>
References: <1455014403-10742-1-git-send-email-rth@twiddle.net>
	<1455014403-10742-15-git-send-email-rth@twiddle.net>
	<20160209162234.GB3678@jhogan-linux.le.imgtec.org>
From: Richard Henderson <rth@twiddle.net>
Message-ID: <56BA1E22.5010708@twiddle.net>
Date: Wed, 10 Feb 2016 04:13:06 +1100
MIME-Version: 1.0
In-Reply-To: <20160209162234.GB3678@jhogan-linux.le.imgtec.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 14/15] tcg-mips: Use mipsr6 instructions in
	branches
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: James Hogan <james.hogan@imgtec.com>
Cc: Leon Alrae <Leon.Alrae@imgtec.com>, qemu-devel@nongnu.org, aurelien@aurel32.net

On 02/10/2016 03:22 AM, James Hogan wrote:
> So to be correct + efficient, it should only put the nop in if the next
> generated instruction is a CTI. I imagine that would be a bit messy /
> fragile, but maybe doable? I haven't looked too deeply.

Ouch, I didn't notice this about these insns.

I suppose this might be rare enough that it's still worth thinking about.  Off 
the top of my head I can't think of any way to save extra state, but perhaps 
just looking back at the previous insn's major opcode is enough when emitting 
any forbidden insn.

For the moment, let's just drop this patch (and probably the one for calls too, 
for the same reason?)


r~