public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jiong Wang <jiong.wang@foss.arm.com>
To: James Greenhalgh <james.greenhalgh@arm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [AArch64, 1/6] Reimplement scalar fixed-point intrinsics
Date: Fri, 27 May 2016 20:01:00 -0000	[thread overview]
Message-ID: <57487B41.8020200@foss.arm.com> (raw)
In-Reply-To: <20160527130344.GF26495@arm.com>



On 27/05/16 14:03, James Greenhalgh wrote:
> On Tue, May 24, 2016 at 09:23:36AM +0100, Jiong Wang wrote:
>>          * config/aarch64/aarch64-simd-builtins.def: Rename to
>>          aarch64-builtins.def.
> Why? We already have some number of intrinsics in here that are not
> strictly SIMD, but I don't see the value in the rename?

Mostly because this builtin infrastructure is handy that I want to
implement some vfp builtins in this .def file instead of implement those
raw structure inside aarch64-builtins.c.

And there maybe more and more such builtins in the future, so I renamed
this file.


Is this OK?

>> +(define_int_iterator FCVT_FIXED2F_SCALAR [UNSPEC_SCVTF_SCALAR UNSPEC_UCVTF_SCALAR])
> Again, do we need the "SCALAR" versions at all?

That's because for scalar fixed-point conversion, we have two types of
instructions to support this.

   * scalar instruction from vfp
   * scalar variant instruction from simd

One is guarded by TARGET_FLOAT, the other is guarded by TARGET_SIMD, and
their instruction format is different, so I want to keep them in
aarch64.md and aarch64-simd.md seperately.

The other reason is these two use different patterns:

   * vfp scalar support conversion between different size, for example,
     SF->DI, DF->SI, so it's using two mode iterators, GPI and GPF, and
     is utilizing the product of the two to cover all supported
     conversions, sfsi, sfdi, dfsi, dfdi, sisf, sidf, disf, didf.

   * simd scalar only support conversion between same size that single
     mode iterator is used to cover sfsi, sisf, dfdi, didf.

For intrinsics implementation, I used builtins backed by vfp scalar
instead of simd scalar which requires the input sitting inside vector 
register.

I remember the simd scalar pattern was here because it's anyway needed
by patch [2/6] which extends it's modes naturally to vector modes. I was
thinking it's better to keep simd scalar variant with this scalar
intrinsics enable patch.

Is this OK?

Thanks.

  reply	other threads:[~2016-05-27 16:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <57430251.6060902@foss.arm.com>
2016-05-24  8:24 ` Jiong Wang
2016-05-27 13:50   ` James Greenhalgh
2016-05-27 20:01     ` Jiong Wang [this message]
2016-06-06 13:39       ` [v2][AArch64, " Jiong Wang
2016-06-08  9:47         ` James Greenhalgh
     [not found]       ` <6af07de4-8179-c0bf-410c-317ef52876dd@foss.arm.com>
2016-06-06 13:39         ` [v2][AArch64, 2/6] Reimplement vector " Jiong Wang
2016-06-08  9:51           ` James Greenhalgh
     [not found]         ` <7cb1e234-46f9-76b4-aefd-1eacabfb4ca7@foss.arm.com>
2016-06-06 13:40           ` [v2][AArch64, 3/6] Reimplement frsqrte intrinsics Jiong Wang
2016-06-08  9:53             ` James Greenhalgh
     [not found]           ` <49a7c4d8-3fdc-8806-a4df-affa742cc5d7@foss.arm.com>
2016-06-06 13:40             ` [v2][AArch64, 4/6] Reimplement frsqrts intrinsics Jiong Wang
2016-06-08  9:57               ` James Greenhalgh
     [not found]             ` <32b5ca55-e60a-42b0-3532-84319e5c0daf@foss.arm.com>
2016-06-06 13:41               ` [v2][AArch64, 5/6] Reimplement fabd intrinsics & merge rtl patterns Jiong Wang
2016-06-08  9:58                 ` James Greenhalgh
     [not found]               ` <1017fc5b-389d-ab41-24bd-491fff8e1a81@foss.arm.com>
2016-06-06 13:41                 ` [v2][AArch64, 6/6] Reimplement vpadd intrinsics & extend rtl patterns to all modes Jiong Wang
2016-06-08  9:59                   ` James Greenhalgh
     [not found] ` <57430271.3070504@foss.arm.com>
     [not found]   ` <5743029C.60208@foss.arm.com>
2016-05-24  8:24     ` [AArch64, 3/6] Reimplement frsqrte intrinsics Jiong Wang
2016-05-27 14:09       ` James Greenhalgh
2016-05-27 19:59         ` Jiong Wang
     [not found]     ` <574302DA.6090803@foss.arm.com>
2016-05-24  8:24       ` [AArch64, 4/6] Reimplement frsqrts intrinsics Jiong Wang
2016-05-27 14:12         ` James Greenhalgh
2016-05-27 15:12           ` Jiong Wang
     [not found]       ` <574302FC.5050701@foss.arm.com>
2016-05-24  8:24         ` [AArch64, 5/6] Reimplement fabd intrinsics & merge rtl patterns Jiong Wang
2016-05-27 14:41           ` James Greenhalgh
2016-05-27 14:52             ` Jiong Wang
     [not found]         ` <5743031A.8060307@foss.arm.com>
2016-05-24  8:24           ` [AArch64, 6/6] Reimplement vpadd intrinsics & extend rtl patterns to all modes Jiong Wang
2016-05-27 14:45             ` James Greenhalgh
2016-05-27 14:51               ` Jiong Wang
2016-05-24  8:24   ` [AArch64, 2/6] Reimplement vector fixed-point intrinsics Jiong Wang

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=57487B41.8020200@foss.arm.com \
    --to=jiong.wang@foss.arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=james.greenhalgh@arm.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 read-only IMAP folder(s) and NNTP newsgroup(s).