From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>, Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] MIPS: memset: Fix `noreorder' issues
Date: Tue, 2 Oct 2018 12:50:00 +0100 (BST) [thread overview]
Message-ID: <alpine.LFD.2.21.1810020209310.20762@eddie.linux-mips.org> (raw)
Hi,
A recent change broke CPU_DADDI_WORKAROUNDS support in memset.S, due to a
delay-slot instruction expanding to multiple hardware operations for the
affected configurations.
The underlying cause is the excessive use of the `noreorder' assembly
mode, while it is only needed in couple of places where either there is a
data dependency between a branch and its delay slot instruction, or there
is a section switch involved that would prevent automatic delay slot
scheduling.
These changes address both problems and for clarity, not to mix multiple
conceptually separate changes and to make backporting easier I made them a
small patch series. See individual change descriptions for details.
This has been build-time and run-time verified with 32-bit and 64-bit
DECstation configurations, build-time verified with big-endian and
little-endian 64-bit SWARM configurations. Build-time verification was
made by running `objdump -d arch/mips/lib/memset.o' with a pristine and
and a patched build to make sure there has been no change in machine code
generation, except for the delay-slot multiple instruction with the 64-bit
CPU_DADDI_WORKAROUNDS DECstation configuration.
Please apply.
Maciej
next reply other threads:[~2018-10-02 11:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 11:50 Maciej W. Rozycki [this message]
2018-10-02 11:50 ` [PATCH 1/2] MIPS: memset: Fix CPU_DADDI_WORKAROUNDS `small_fixup' regression Maciej W. Rozycki
2018-10-02 11:50 ` [PATCH 2/2] MIPS: memset: Limit excessive `noreorder' assembly mode use Maciej W. Rozycki
2018-10-11 16:36 ` [PATCH 0/2] MIPS: memset: Fix `noreorder' issues Paul Burton
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.21.1810020209310.20762@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=paul.burton@mips.com \
--cc=ralf@linux-mips.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®