From: "Wilco Dijkstra" <wdijkstr@arm.com>
To: "James Greenhalgh" <James.Greenhalgh@arm.com>
Cc: "'GCC Patches'" <gcc-patches@gcc.gnu.org>
Subject: RE: [PATCH][AArch64] Use conditional negate for abs expansion
Date: Mon, 27 Apr 2015 16:57:00 -0000 [thread overview]
Message-ID: <000901d0810b$3d6ab0d0$b8401270$@com> (raw)
In-Reply-To: <20150427162640.GB1993@arm.com>
> James Greenhalgh wrote:
> On Mon, Apr 27, 2015 at 02:42:36PM +0100, Wilco Dijkstra wrote:
> > > -----Original Message-----
> > > From: Wilco Dijkstra [mailto:wdijkstr@arm.com]
> > > Sent: 03 March 2015 16:19
> > > To: GCC Patches
> > > Subject: [PATCH][AArch64] Use conditional negate for abs expansion
> > >
> > > Expand abs into a compare and conditional negate. This is the most obvious expansion,
> enables
> > > merging of the comparison into ALU instructions and is faster on all implementations.
> > > Bootstrapped & regression tested.
> > >
> > > int f(int x) { return abs (x + 1); }
> > >
> > > Before:
> > > add w0, w0, 1
> > > sxtw x0, w0
> > > eor x1, x0, x0, asr 63
> > > sub x1, x1, x0, asr 63
> > > mov x0, x1
> > > ret
> > >
> > > After:
> > > adds w0, w0, 1
> > > csneg w0, w0, w0, pl
> > > ret
> > >
> > > ChangeLog:
> > >
> > > 2015-03-03 Wilco Dijkstra <wdijkstr@arm.com>
> > >
> > > * gcc/config/aarch64/aarch64.md (absdi2): optimize abs expansion.
> > > (csneg3<mode>_insn): enable expansion of pattern.
> > > * gcc/testsuite/gcc.target/aarch64/abs_1.c (abs64): update test
> > > for new abs expansion. (abs64_in_dreg): likewise.
>
>
> This looks like it breaks support for abs in a D register (for example
> at the end of a loop, or extracted from Neon Intrinsics, etc).
>
> e.g. (totally contrived...)
>
> int64x1_t
> abs_max (int64x2_t x, int64_t *wb)
> {
> int64_t y = vgetq_lane_s64 (x, 0);
> if (y < 0)
> y = -y;
> return vdup_n_s64 (y);
> }
>
> Which currently generates:
>
> abs_max:
> abs d0, d0
> ret
>
> I suppose we don't need to worry too much about that (and the current
> implementation doesn't seem to catch it reliably anyway), but it would be
> good if we could keep the support - even if it is rarely used.
Well it may be possible to write a peephole for this rare case, but I hope
people would use a vabs if that's what they wanted...
Wilco
next prev parent reply other threads:[~2015-04-27 16:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-27 13:42 Wilco Dijkstra
2015-04-27 16:26 ` James Greenhalgh
2015-04-27 16:57 ` Wilco Dijkstra [this message]
2015-05-14 9:43 ` James Greenhalgh
2015-05-14 13:25 ` Wilco Dijkstra
-- strict thread matches above, loose matches on Subject: below --
2015-03-03 16:19 Wilco Dijkstra
2015-03-04 9:18 ` Maxim Kuvyrkov
2015-03-04 12:31 ` Wilco Dijkstra
2015-03-04 12:49 ` Maxim Kuvyrkov
2015-03-04 15:00 ` Wilco Dijkstra
2015-03-04 15:16 ` Maxim Kuvyrkov
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='000901d0810b$3d6ab0d0$b8401270$@com' \
--to=wdijkstr@arm.com \
--cc=James.Greenhalgh@arm.com \
--cc=gcc-patches@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).