From: Segher Boessenkool <segher@kernel.crashing.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Boqun Feng <boqun.feng@gmail.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Michael Jeanson <mjeanson@efficios.com>
Subject: Re: Failure to build librseq on ppc
Date: Thu, 9 Jul 2020 12:31:40 -0500 [thread overview]
Message-ID: <20200709173140.GK3598@gate.crashing.org> (raw)
In-Reply-To: <429958629.6348.1594301598584.JavaMail.zimbra@efficios.com>
On Thu, Jul 09, 2020 at 09:33:18AM -0400, Mathieu Desnoyers wrote:
> > The way this all uses r17 will likely not work reliably.
>
> r17 is only used as a temporary register within the inline assembler, and it is
> in the clobber list. In which scenario would it not work reliably ?
This isn't clear at all, that is the problem.
> > The way multiple asm statements are used seems to have missing
> > dependencies between the statements.
>
> I'm not sure I follow here. Note that we are injecting the CPP macros into
> a single inline asm statement as strings.
Yeah... more trickiness.
> > And done macro-mess this, you want to be able to debug it, and you need
> > other people to be able to read it!
>
> I understand that looking at macros can be cumbersome from the perspective
> of a reviewer only interested in a single architecture,
No, from the perspective of *any* reviewer.
> However, from my perspective, as a maintainer who must maintain similar code
> for x86 32/64, powerpc 32/64, arm, aarch64, s390, s390x, mips 32/64, and likely
> other architectures in the future, the macros abstracting 32-bit and 64-bit
> allow to eliminate code duplication for each architecture with 32-bit and 64-bit
> variants, which is better for maintainability.
IMNSHO it is MUCH better to just have simple separate implementations
for each. They differ in *all* details.
Or have static inline functions, with proper dependencies, instead of
nasty text macros.
But it's your code, do what you want :-)
Segher
prev parent reply other threads:[~2020-07-09 17:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-07 19:17 Failure to build librseq on ppc Mathieu Desnoyers
2020-07-08 0:59 ` Segher Boessenkool
2020-07-08 12:27 ` Michael Ellerman
2020-07-08 23:53 ` Segher Boessenkool
2020-07-09 0:01 ` Mathieu Desnoyers
2020-07-09 0:18 ` Segher Boessenkool
2020-07-09 13:43 ` Mathieu Desnoyers
2020-07-09 17:37 ` Segher Boessenkool
2020-07-09 17:42 ` Mathieu Desnoyers
2020-07-09 17:56 ` Mathieu Desnoyers
2020-07-09 20:46 ` Segher Boessenkool
2020-07-09 20:57 ` Mathieu Desnoyers
2020-07-09 20:31 ` Segher Boessenkool
2020-07-08 12:33 ` Mathieu Desnoyers
2020-07-08 14:00 ` Mathieu Desnoyers
2020-07-08 14:21 ` Christophe Leroy
2020-07-08 14:32 ` Mathieu Desnoyers
2020-07-08 16:11 ` Christophe Leroy
2020-07-09 0:15 ` Segher Boessenkool
2020-07-09 0:10 ` Segher Boessenkool
2020-07-09 13:33 ` Mathieu Desnoyers
2020-07-09 17:31 ` Segher Boessenkool [this message]
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=20200709173140.GK3598@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=boqun.feng@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mjeanson@efficios.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.