On Fri, Feb 28, 2020 at 05:31:56PM +0100, Jakub Jelinek wrote:
> On Fri, Feb 28, 2020 at 04:23:03PM +, GT wrote:
> > Do we want to change the name and title of the document since Segher
> > doesn't believe it
> > is an ABI. My initial suggestion: "POWER Architecture Specification of
> >
‐‐‐ 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
On Mon, Mar 02, 2020 at 09:40:59PM +, GT wrote:
> Searching openmp.org located document "OpenMP API Examples". The relevant
> example
> for inbranch/notinbranch shows very simple functions (SIMD.6.c). GCC testsuite
> functions are similarly simple.
> Wouldn't the same effect be achieved by
‐‐‐ Original Message ‐‐‐
On Monday, March 2, 2020 3:31 PM, Jakub Jelinek wrote:
> On Mon, Mar 02, 2020 at 08:20:01PM +, GT wrote:
>
> > Which raises the question: what use-case motivated allowing the compiler
> > to auto-vectorize user defined functions? From having manually created
‐‐‐ 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
On Mon, Mar 02, 2020 at 08:20:01PM +, GT wrote:
> Which raises the question: what use-case motivated allowing the compiler
> to auto-vectorize user defined functions? From having manually created vector
The feature made it into the OpenMP standard (already OpenMP 4.0) and so got
implemented
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 defined in PowerISA v2.07)." We will plan to only change values
in case
a different vector length is defined in
Bill Schmidt writes:
> One tiny nit on the document: For the "b" value, let's just say "VSX"
> rather than
> "VSX as defined in PowerISA v2.07)." We will plan to only change
> values in case
> a different vector length is defined in future.
That change would have more implications: all
In 2/28/20 10:31 AM, Jakub Jelinek wrote:
On Fri, Feb 28, 2020 at 04:23:03PM +, GT wrote:
Do we want to change the name and title of the document since Segher doesn't
believe it
is an ABI. My initial suggestion: "POWER Architecture Specification of Scalar
Function
to Vector Function
‐‐‐ 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:
> > >
On Fri, Feb 28, 2020 at 04:23:03PM +, GT wrote:
> Do we want to change the name and title of the document since Segher doesn't
> believe it
> is an ABI. My initial suggestion: "POWER Architecture Specification of Scalar
> Function
> to Vector Function Mapping".
It is an ABI, similarly like
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://sourceware.org/glibc/wiki/HomePage?action=AttachFile=view=powerarchvectfuncabi.html
Looks good. Can you please also remove the 'c' ABI from the mangling, as
earlier agreed?
On 2/27/20 12:48 PM, GT wrote:
‐‐‐ 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
‐‐‐ 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
On 2/27/20 9:30 AM, Jakub Jelinek wrote:
On Thu, Feb 27, 2020 at 09:19:25AM -0600, Bill Schmidt wrote:
On 2/27/20 8: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
On Thu, Feb 27, 2020 at 09:19:25AM -0600, Bill Schmidt wrote:
> On 2/27/20 8: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.
On 2/27/20 8: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 better off warning and
ignoring the directive, leaving the code
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 better off warning and
> ignoring the directive, leaving the code in scalar form?
Depends on the exact
On 2/26/20 8:31 AM, Jakub Jelinek wrote:
On Wed, Feb 26, 2020 at 07:55:53AM -0600, Bill Schmidt wrote:
The hope is that we can create a vectorized version that returns values
in registers rather than the by-ref parameters, and add code to GCC to
copy things around correctly following the call.
On 2/27/20 4:52 AM, Segher Boessenkool wrote:
On Tue, Feb 25, 2020 at 07:43:09PM -0600, Bill Schmidt wrote:
The reason that homogeneous aggregates matter (at least somewhat) is that
the ABI ^H^H^H^HAPI requires establishing a calling convention and a name-
mangling formula that includes the
On Thu, Feb 27, 2020 at 11:56:49AM +0100, Richard Biener wrote:
> > > This calling convention would also be useful in the future for vectorizing
> > > functions that return complex values either by value or by reference.
> >
> > Only by value, you really don't know what the code does if something
On Wed, Feb 26, 2020 at 3:31 PM Jakub Jelinek wrote:
>
> On Wed, Feb 26, 2020 at 07:55:53AM -0600, Bill Schmidt wrote:
> > The hope is that we can create a vectorized version that returns values
> > in registers rather than the by-ref parameters, and add code to GCC to
> > copy things around
On Tue, Feb 25, 2020 at 07:43:09PM -0600, Bill Schmidt wrote:
> The reason that homogeneous aggregates matter (at least somewhat) is that
> the ABI ^H^H^H^HAPI requires establishing a calling convention and a name-
> mangling formula that includes the length of parameters and return values.
>
Hi!
On Tue, Feb 25, 2020 at 07:43:09PM -0600, Bill Schmidt wrote:
> On 2/25/20 12:45 PM, Segher Boessenkool wrote:
> >I don't agree we should have a new ABI, and an API (which this *is* as
> >far as I can tell) works fine on *any* ABI. Homogeneous aggregates has
> >nothing to do with anything
On Wed, Feb 26, 2020 at 07:55:53AM -0600, Bill Schmidt wrote:
> The hope is that we can create a vectorized version that returns values
> in registers rather than the by-ref parameters, and add code to GCC to
> copy things around correctly following the call. Ideally the signature of
> the
On 2/26/20 2:18 AM, Jakub Jelinek wrote:
On Tue, Feb 25, 2020 at 07:43:09PM -0600, Bill Schmidt wrote:
The reason that homogeneous aggregates matter (at least somewhat) is that
the ABI ^H^H^H^HAPI requires establishing a calling convention and a name-
mangling formula that includes the length
On Wed, Feb 26, 2020 at 2:46 PM Jakub Jelinek wrote:
>
> On Wed, Feb 26, 2020 at 10:32:17AM -0300, Tulio Magno Quites Machado Filho
> wrote:
> > Jakub Jelinek writes:
> >
> > > Can you please explain how do you want to pass the
> > > void sincos (double, double *, double *);
> > > arguments? I
On Wed, Feb 26, 2020 at 10:32:17AM -0300, Tulio Magno Quites Machado Filho
wrote:
> Jakub Jelinek writes:
>
> > Can you please explain how do you want to pass the
> > void sincos (double, double *, double *);
> > arguments? I must say it isn't entirely clear from the document.
> > You talk
Jakub Jelinek writes:
> Can you please explain how do you want to pass the
> void sincos (double, double *, double *);
> arguments? I must say it isn't entirely clear from the document.
> You talk there about double[2], but sincos certainly doesn't have such an
> argument.
The plan [1] is to
On Tue, Feb 25, 2020 at 07:43:09PM -0600, Bill Schmidt wrote:
> The reason that homogeneous aggregates matter (at least somewhat) is that
> the ABI ^H^H^H^HAPI requires establishing a calling convention and a name-
> mangling formula that includes the length of parameters and return values.
>
On 2/25/20 12:45 PM, Segher Boessenkool wrote:
Hi!
On Tue, Feb 25, 2020 at 04:53:17PM +, GT wrote:
‐‐‐ Original Message ‐‐‐
On Sunday, February 23, 2020 11:45 AM, Bill Schmidt
wrote:
As I just wrote on gcc-patches, we should disable libmvec for powerpc64.
The vector ABI as
On Tue, 25 Feb 2020, GT wrote:
> 2. In GCC making SIMD clones available only for powerpc64le should be
> sufficient to guarantee that the Vector Function ABI is applied only for
> systems implementing the ELFv2 ABI. Right? Then, which macro is to be
> tested for in rs6000_simd_clone_usable? I
GT writes:
> Are we all agreed that the POWER Vector Function ABI will be implemented only
> for powerpc64le?
>
> If so, here are a few more questions:
>
> 1. The GLIBC implementation has files Makefile, Versions, configure,
> configure.ac among others
> in directory
Hi!
On Tue, Feb 25, 2020 at 04:53:17PM +, GT wrote:
> ‐‐‐ Original Message ‐‐‐
> On Sunday, February 23, 2020 11:45 AM, Bill Schmidt
> wrote:
> > As I just wrote on gcc-patches, we should disable libmvec for powerpc64.
> > The vector ABI as written isn't compatible with ELFv1. We
‐‐‐ 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 exactly where/how to link
> > > the Power
36 matches
Mail list logo
