‐‐‐ Original Message ‐‐‐
On Thursday, August 20, 2020 1:48 PM, Segher Boessenkool
wrote:
> On Thu, Aug 20, 2020 at 04:19:36PM +0000, GT wrote:
>
> > > Great! Please repost with what I already pointed out fixed, that
> > > explanation added, and working li
‐‐‐ Original Message ‐‐‐
On Thursday, August 13, 2020 5:00 PM, Jakub Jelinek wrote:
> On Thu, Aug 13, 2020 at 08:40:22PM +0000, GT wrote:
>
> > I'm looking at ix86_simd_clone_adjust and also aarch64_simd_clone_adjust.
> > The latter is
> > much simpler and I
‐‐‐ Original Message ‐‐‐
On Tuesday, August 18, 2020 5:32 PM, Segher Boessenkool
wrote:
> On Tue, Aug 18, 2020 at 07:14:19PM +0000, GT wrote:
>
> > > That sounds like libmvec?
> > > I still don't know what this is.
> >
> > Yes, it is libmvec.
>
‐‐‐ Original Message ‐‐‐
On Monday, August 17, 2020 5:28 PM, Segher Boessenkool
wrote:
> On Mon, Aug 17, 2020 at 05:44:46PM +0000, GT wrote:
>
> > > This is about the Power binding to some OpenMP API, right? It has
> > > nothing to do with "vector" o
‐‐‐ Original Message ‐‐‐
On Thursday, August 13, 2020 6:49 PM, Segher Boessenkool
wrote:
> Hi!
>
> This is about the Power binding to some OpenMP API, right? It has
> nothing to do with "vector" or "ABI" -- we have vectors already, and
> we have ABIs already, more than enough of each.
>
‐‐‐ Original Message ‐‐‐
On Monday, August 10, 2020 2:07 PM, Jakub Jelinek wrote:
> On Mon, Aug 10, 2020 at 05:29:49PM +0000, GT wrote:
>
> > > For PowerPC, if all you want to support is b which requires VSX, then the
> > > right thing is for !TREE_P
‐‐‐ Original Message ‐‐‐
On Friday, August 7, 2020 4:59 PM, Jakub Jelinek wrote:
> On Fri, Aug 07, 2020 at 08:35:52PM +, Bert Tenjy via Gcc-patches wrote:
>
> > The document describing POWER Architecture Vector Function interface is
> > tentatively at:
> >
‐‐‐ Original Message ‐‐‐
On Sunday, February 16, 2020 7:06 PM, Segher Boessenkool
wrote:
> On Sat, Feb 15, 2020 at 05:22:09PM +0000, GT wrote:
> > I have not been able to configure protonmail for either git imap-send or
> > send-email.
>
> Do you use git for
‐‐‐ Original Message ‐‐‐
On Thursday, March 5, 2020 6:59 PM, Segher Boessenkool
wrote:
> On Thu, Mar 05, 2020 at 05:04:16PM +0000, GT wrote:
>
> > 2. Multiple other testcases in testsuite/gcc.dg/vect/ have this line at
> > the top:
> > /* { dg-additional-
‐‐‐ Original Message ‐‐‐
On Thursday, March 5, 2020 6:59 PM, Segher Boessenkool
wrote:
> On Thu, Mar 05, 2020 at 05:04:16PM +0000, GT wrote:
>
> > At the top of that file is dejagnu directive:
> > /* { dg-require-effective-target vect_int } */
> >
>
‐‐‐ Original Message ‐‐‐
On Thursday, March 5, 2020 6:59 PM, Segher Boessenkool
wrote:
> On Thu, Mar 05, 2020 at 05:04:16PM +0000, GT wrote:
>
> > At the top of that file is dejagnu directive:
> > /* { dg-require-effective-target vect_int } */
> >
>
I tried the make command below:
make check RUNTESTFLAGS="*.exp=*simd*"
gcc.log did not have any output indicating that it ran
.../gcc/testsuite/gcc.dg/vect/vect-simd-2.c
At the top of that file is dejagnu directive:
/* { dg-require-effective-target vect_int } */
1. How do I check to see if
‐‐‐ Original Message ‐‐‐
On Monday, March 2, 2020 12:14 PM, Bill Schmidt wrote:
> On 3/2/20 11:10 AM, Tulio Magno Quites Machado Filho wrote:
>
> > Bill Schmidt writes:
> >
> > > One tiny nit on the document: For the "b" value, let's just say
> > > "VSX" rather than
> > > "VSX as
‐‐‐ Original Message ‐‐‐
On Monday, March 2, 2020 4:59 PM, Jakub Jelinek wrote:
> Indeed, there aren't any yet on the vectorizer side, I thought I've
> implemented it
> already in the vectorizer but apparently didn't, just the omp-simd-clone.c
> part is
> implemented (the more
‐‐‐ Original Message ‐‐‐
On Monday, March 2, 2020 3:31 PM, Jakub Jelinek wrote:
> On Mon, Mar 02, 2020 at 08:20:01PM +0000, GT wrote:
>
> > Which raises the question: what use-case motivated allowing the compiler
> > to auto-vectorize user defined functions? From havin
‐‐‐ Original Message ‐‐‐
On Thursday, February 27, 2020 9:52 AM, Jakub Jelinek wrote:
> On Thu, Feb 27, 2020 at 08:47:19AM -0600, Bill Schmidt wrote:
>
> > But is this actually a good idea? It seems to me this will generate lousy
> > code in the absence of hardware support. Won't we be
‐‐‐ Original Message ‐‐‐
On Thursday, February 27, 2020 4:32 PM, Bill Schmidt
wrote:
> On 2/27/20 2:21 PM, Bill Schmidt wrote:
>
> > On 2/27/20 12:48 PM, GT wrote:
> >
> > > Done.
> > >
> > > The updated document is at:
> > > https:
‐‐‐ Original Message ‐‐‐
On Thursday, February 27, 2020 9:26 AM, Bill Schmidt
wrote:
>
> Upon reflection, I agree. Bert, we need to make changes to the document to
> reflect this:
>
> (1) "Calling convention" should refer to ELFv1 for powerpc64 and ELFv2 for
> powerpc64le.
Done. Have
‐‐‐ Original Message ‐‐‐
On Sunday, February 23, 2020 11:45 AM, Bill Schmidt
wrote:
> On 2/21/20 6:49 AM, Tulio Magno Quites Machado Filho wrote:
>
> > +Bill, +Segher
> >
> > GT writes:
> >
> > > Can I have until tomorrow morning to figure out exa
‐‐‐ Original Message ‐‐‐
On Monday, February 24, 2020 10:20 AM, Bill Schmidt
wrote:
> So, I can answer a small amount of this, but I will say that overall, design
> or implementation documentation seems to be between lacking and nonexistent.
>
> This has to do with "#pragma omp simd"
‐‐‐ Original Message ‐‐‐
On Wednesday, February 19, 2020 12:33 PM, Bill Schmidt
wrote:
> > The reason 'c' was added to the ABI is this mailing list discussion:
> > https://sourceware.org/ml/libc-alpha/2019-11/msg00765.html
> > As long as 'b' specifies that the VSX functionality is that
‐‐‐ Original Message ‐‐‐
On Wednesday, February 19, 2020 5:52 PM, Joseph Myers
wrote:
> On Wed, 19 Feb 2020, GT wrote:
>
> > 1. In the Vector Function ABI document, under section "Vector Function
> > Name Mangling", state that all vec
‐‐‐ Original Message ‐‐‐
On Wednesday, February 19, 2020 12:33 PM, Bill Schmidt
wrote:
> >
> > The reason 'c' was added to the ABI is this mailing list discussion:
> > https://sourceware.org/ml/libc-alpha/2019-11/msg00765.html
> > As long as 'b' specifies that the VSX functionality is
‐‐‐ Original Message ‐‐‐
On Sunday, February 16, 2020 3:10 PM, GT wrote:
> ‐‐‐ Original Message ‐‐‐
> On Friday, February 14, 2020 5:09 PM, Jakub Jelinek ja...@redhat.com wrote:
>
> > On Fri, Feb 14, 2020 at 10:02:39PM +, GT wrote:
> &g
‐‐‐ Original Message ‐‐‐
On Friday, February 14, 2020 5:09 PM, Jakub Jelinek ja...@redhat.com wrote:
> On Fri, Feb 14, 2020 at 10:02:39PM +0000, GT wrote:
>
> > > > Function rs6000_simd_clone_adjust, even though it's body is empty,
> > > > cannot simply be re
‐‐‐ Original Message ‐‐‐
On Friday, February 14, 2020 6:46 PM, Segher Boessenkool
wrote:
> On Fri, Feb 14, 2020 at 08:24:30PM +0000, GT wrote:
>
> > Function rs6000_simd_clone_adjust, even though it's body is empty,
> > cannot simply be removed. I tried it. It resu
‐‐‐ Original Message ‐‐‐
On Friday, February 14, 2020 3:38 PM, Jakub Jelinek wrote:
> On Fri, Feb 14, 2020 at 08:24:30PM +0000, GT wrote:
>
> > Function rs6000_simd_clone_adjust, even though it's body is empty,
> > cannot simply be removed. I tried it. It resulted in I
Function rs6000_simd_clone_adjust, even though it's body is empty,
cannot simply be removed. I tried it. It resulted in ICE. In my
view, leaving it empty is preferable to modifying other files
unrelated to rs6000.c in order to avoid having a function whose
body is empty.
Bert.
‐‐‐ Original Message ‐‐‐
On Wednesday, January 15, 2020 3:20 PM, GT wrote:
> ‐‐‐ Original Message ‐‐‐
> On Thursday, January 9, 2020 8:42 AM, Richard Biener
> richard.guent...@gmail.com wrote:
>
> > As for the other question for testing you probably want to
‐‐‐ Original Message ‐‐‐
On Thursday, January 9, 2020 8:42 AM, Richard Biener
wrote:
>
> 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
‐‐‐ Original Message ‐‐‐
On Monday, December 9, 2019 3:39 AM, Richard Biener
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.
> >
‐‐‐ Original Message ‐‐‐
On Monday, December 9, 2019 3:39 AM, Richard Biener
wrote:
> 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
‐‐‐ Original Message ‐‐‐
On Monday, December 9, 2019 12:36 PM, GT wrote:
> ‐‐‐ Original Message ‐‐‐
> On Monday, December 9, 2019 3:39 AM, Richard Biener
> richard.guent...@gmail.com wrote:
>
> > > I'm modifying the code trying to get complex doubl
‐‐‐ Original Message ‐‐‐
On Monday, December 9, 2019 3:39 AM, Richard Biener richard.guent...@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
‐‐‐ Original Message ‐‐‐
On Friday, December 6, 2019 12:43 PM, Richard Biener richard.guent...@gmail.com
wrote:
...
...
> > Are we certain the change we want is to support _Complex double so that
> > cexpi is auto-vectorized?
> > Looking at the resulting executable of the code with
‐‐‐ Original Message ‐‐‐
On Friday, December 6, 2019 6:38 AM, Richard Biener
wrote:
> On Fri, Dec 6, 2019 at 12:15 PM Jakub Jelinek ja...@redhat.com wrote:
>
> > On Fri, Dec 06, 2019 at 11:48:03AM +0100, Richard Biener wrote:
> >
> > > So I used
> > > void sincos(double x, double *sin,
‐‐‐ Original Message ‐‐‐
On Thursday, December 5, 2019 4:44 AM, Richard Biener
wrote:
...
...
...
> >
> > I'm trying to identify the source code which needs modification but I need
> > help proceeding.
> > I am comparing two compilations: The first is a simple file with a call to
>
‐‐‐ Original Message ‐‐‐
On Wednesday, November 27, 2019 3:19 AM, Richard Biener
wrote:
...
> > Questions:
> >
> > 1. Should we aim to provide a vectorized version of __builtin_cexpi? If
> > so, it would have
> > to be a PPC64-only vector __builtin-cexpi, right?
> >
> > 2. Or
> >
> > i wonder if gcc can auto-vectorize scalar sincos
> > calls, the vectorizer seems to want the calls to
> > have no side-effect, but attribute pure or const
> > is not appropriate for sincos (which has no return
> > value but takes writable pointer args)
>
> We have __builtin_cexpi for that
‐‐‐ Original Message ‐‐‐
On Monday, September 30, 2019 9:52 AM, Szabolcs Nagy
wrote:
> On 27/09/2019 20:23, GT wrote:
>
> > I am attempting to create a vector version of sincos for PPC64.
> > The relevant discussion thread is on the GLIBC libc-alpha mailing
I am attempting to create a vector version of sincos for PPC64.
The relevant discussion thread is on the GLIBC libc-alpha mailing list.
Navigate it beginning at
https://sourceware.org/ml/libc-alpha/2019-09/msg00334.html
The intention is to reuse as much as possible from the existing GCC
41 matches
Mail list logo
