This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PPC64 libmvec implementation of sincos
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: GT <tnggil at protonmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, nd <nd at arm dot com>, Bill Schmidt <wschmidt at linux dot ibm dot com>
- Date: Thu, 9 Jan 2020 14:42:48 +0100
- Subject: Re: PPC64 libmvec implementation of sincos
- References: <GcaLIHZaxSm2PVhunNuxEwEJB-BC3PeXIBlmYb6eMw54vZQ_KF6uBjlTgWmWtPNIMMeXu7UyYg797u1vV1_GS2Qv3ThxrUeORQD0wcddwwo=@protonmail.com> <JJk2TKaV0tVHVY2AyyGtw7X5lNw90vm80Fhu9YcgQh5QOWlrcyL8bzgSYETL8G9stKmaOX5lYmSAaX6hs9xLnI8iuCTRD0xio9vVxhtApYs=@protonmail.com> <CAFiYyc3FO6jgarVbNn4=kckgw7UYHUaHYxiCv4ZJTMRPuy1dMw@mail.gmail.com> <20191206111540.GC10088@tucnak> <CAFiYyc2WJrh2BW5891XhjxM0SsJkxbSOoOh58AeTBmz+Bed9Tw@mail.gmail.com> <hd-6QLiJS0PVrxLBOkT_w0FiGyHomRJkmlR_hRrIGCHZJXhITGVMZ6fzbOFOOoqt6fZ3E1m5tDhtzwDfbeeusk1IdGwsONZFF2nIA4WvxMw=@protonmail.com> <CCED278B-4638-4238-A798-9FD4C98EF2BE@gmail.com> <lyW7bEDQcGe8hV1r_r-252urMynbbu4bJHT-mEJOb4rljDo4-H-BpPiZcKO3EVm2p2EkkvF0Xl_CLCFRael9C5TiBdoNLJ4TCEXbNTPe8iU=@protonmail.com> <CAFiYyc0Pr58VFoR+tKrgi_pvO3OGcHnm4JH=itYF+NdvaqmJUQ@mail.gmail.com> <Ob53m7cSAsYBYj1DHIj9VH8DF5Hihjngpocha0Ctn5zbjEYG8ixA7ZoKAzR4Hm_2XT74neDGiZukyW_c95ppV_dG4XKwRDrybQAfiOUGhSo=@protonmail.com>
On Sat, Dec 28, 2019 at 9:01 PM GT <tnggil@protonmail.com> wrote:
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, December 9, 2019 3:39 AM, Richard Biener <richard.guenther@gmail.com> wrote:
>
> > > I'm modifying the code trying to get complex double accepted as a valid type by the vectorizer.
> > > This is the first time I'm dealing with GCC source so I ask for some patience.
> > > Function mode_for_vector in gcc/stor-layout.c requires a new else-if for complex double. I cannot
> > > seem to find a header file where MIN_MODE_VECTOR_FLOAT and similar macros are defined. I expect
> > > a new MIN_MODE_COMPLEX_VECTOR_FLOAT to be defined in the same file as the existing similar macros.
> > > How do I go about making this change?
> >
> > You don't want to do it this way but map _Complex double to a vector
> > of 2 * n doubles instead.
> > Look into get_related_vectype_for_scalar_type where it alreday has
> > code to "change" the
> > scalar type into something that fits what we allow for vectors.
> >
>
> I need more guidance on how to proceed here. Function mode_for_vector is called by
> build_vector_type_for_mode. The latter is called by get_related_vectype_for_scalar_type,
> which you suggested to study for a preferred implementation. The code in mode_for_vector
> relies on the relationship that vector mode E_V2DFmode is composed of E_DFmode scalars.
> The complex argument has mode E_DCmode. Where should I create a relationship between
> E_V2DFmode and E_DCmode so that mode_for_vector returns the appropriate vector mode?
> The solution has to be general so that single precision float complex vectorization is
> also supported.
For _Complex types you call mode_for_vector with the component type
but twice the number
of elements. I would not suggest to try making a vector type with
complex components.
As for the other question for testing you probably want to provide a
OMP simd declaration
of a function like
_Complex double mycexpi (double);
and make a testcase like
void foo (_Complex double * __restrict out, double *in)
{
for (int i = 0; i < 1024; ++i)
{
out[i] = mycexpi (in[i]);
}
}
or eventually with two output arrays and explicit __real/__imag
processing. The real
and main question is how is the OMP SIMD declaration of mycexpi looking like?
So I'd completely side-step sincos() and GCCs sincos() ->
__builtin_cepxi transform
and concentrate on OMP SIMD of a function with the signature we need to handle.
Richard.
> Bert.