From: Segher Boessenkool <segher@kernel.crashing.org>
To: Gabriel Paubert <paubert@iram.es>
Cc: Sathvika Vasireddy <sathvika@linux.vnet.ibm.com>,
naveen.n.rao@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
Daniel Axtens <dja@axtens.net>
Subject: Re: [PATCH 1/2] powerpc/sstep: Add emulation support for ‘setb’ instruction
Date: Fri, 23 Apr 2021 11:57:42 -0500 [thread overview]
Message-ID: <20210423165742.GO27473@gate.crashing.org> (raw)
In-Reply-To: <20210423102657.GA22427@lt-gp.iram.es>
On Fri, Apr 23, 2021 at 12:26:57PM +0200, Gabriel Paubert wrote:
> On Thu, Apr 22, 2021 at 06:26:16PM -0500, Segher Boessenkool wrote:
> > > But this can be made jump free :-):
> > >
> > > int tmp = regs->ccr << ra;
> > > op->val = (tmp >> 31) | ((tmp >> 30) & 1);
> >
> > The compiler will do so automatically (or think of some better way to
> > get the same result); in source code, what matters most is readability,
> > or clarity in general (also clarity to the compiler).
>
> I just did a test (trivial code attached) and the original code always
> produces one conditional branch at -O2, at least with the cross-compiler
> I have on Debian (gcc 8.3). I have tested both -m32 and -m64. The 64 bit
> version produces an unnecessary "extsw", so I wrote the second version
> splitting the setting of the return value which gets rid of it.
That is an older compiler, and it will be out-of-service any day now.
It depends on what compiler flags you use, and what version of the ISA
you are targetting.
> The second "if" is fairly simple to optimize and the compiler does it
> properly.
Yeah.
> Of course with my suggestion the compiler does not produce any branch.
> But it needs a really good comment.
Or you could try and help improve the compiler ;-) You can do this
without writing compiler code yourself, by writing up some good
enhancement request in bugzilla.
The wider and more OoO the processors become, the more important it
becomes to have branch-free code, in situations where the branches would
not be well-predictable.
> > (Right shifts of negative numbers are implementation-defined in C,
> > fwiw -- but work like you expect in GCC).
>
> Well, I'm not worried about it, since I'd expect a compiler that does
> logical right shifts on signed valued to break so much code that it
> would be easily noticed (also in the kernel).
Yup. And it *is* defined for signed values, as long as they are
non-negative (the common case).
> > > > Also, even people who write LE have the bigger end on the left normally
> > > > (they just write some things right-to-left, and other things
> > > > left-to-right).
> > >
> > > Around 1985, I had a documentation for the the National's 32032
> > > (little-endian) processor family, and all the instruction encodings were
> > > presented with the LSB on the left and MSB on the right.
> >
> > Ouch! Did they write "regular" numbers with the least significant digit
> > on the left as well?
>
> No, they were not that sadistic!
But more inconsistent :-)
Segher
next prev parent reply other threads:[~2021-04-23 17:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-16 7:02 [PATCH 0/2] powerpc/sstep: Add emulation support and tests for 'setb' instruction Sathvika Vasireddy
2021-04-16 7:02 ` [PATCH 1/2] powerpc/sstep: Add emulation support for ‘setb’ instruction Sathvika Vasireddy
2021-04-16 7:44 ` Daniel Axtens
2021-04-20 6:26 ` Naveen N. Rao
2021-04-21 7:30 ` Michael Ellerman
2021-04-22 10:01 ` Naveen N. Rao
2021-04-23 13:29 ` Michael Ellerman
2021-04-27 16:44 ` Naveen N. Rao
2021-04-22 19:13 ` Segher Boessenkool
2021-04-22 22:16 ` Gabriel Paubert
2021-04-22 23:26 ` Segher Boessenkool
2021-04-23 10:26 ` Gabriel Paubert
2021-04-23 16:57 ` Segher Boessenkool [this message]
2021-04-24 16:13 ` Daniel Axtens
2021-04-16 7:02 ` [PATCH 2/2] powerpc/sstep: Add tests for setb instruction Sathvika Vasireddy
2021-04-20 17:37 ` Naveen N. Rao
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=20210423165742.GO27473@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=dja@axtens.net \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=naveen.n.rao@linux.ibm.com \
--cc=paubert@iram.es \
--cc=sathvika@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).