Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
‐‐‐ Original Message ‐‐‐ On Thursday, August 20, 2020 1:48 PM, Segher Boessenkool wrote: > On Thu, Aug 20, 2020 at 04:19:36PM +, GT wrote: > > > > Great! Please repost with what I already pointed out fixed, that > > > explanation added, and working links to the documentation? > > > > Are you ok with the titles of the patch and this document? > > https://sourceware.org/glibc/wiki/HomePage?action=AttachFile=view=powerarchvectfuncabi.html > > It is very misleading. You can undo some of the damage in the first > lines of the commit message, but you can also just fix the title itself, > so that anyone can see what this is about even before reading the > message (which is what a mail subject is for!) > > Segher I have: 1. Changed the title of this document. 2. Removed all references within the document describing itself as an ABI. 3. Added a new introductory paragraph that should hopefully make clearer the doc's purpose. Use the new link below. There's has been a name change in the link as well. https://sourceware.org/glibc/wiki/HomePage?action=AttachFile=view=powerarchvectfuncspec.html Bert.
Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
‐‐‐ Original Message ‐‐‐
On Thursday, August 13, 2020 5:00 PM, Jakub Jelinek wrote:
> On Thu, Aug 13, 2020 at 08:40:22PM +, GT wrote:
>
> > I'm looking at ix86_simd_clone_adjust and also aarch64_simd_clone_adjust.
> > The latter is
> > much simpler and I see how I would add PPC attribute "vsx" similarly. If I
> > was to follow
> > the ix86_simd_clone_adjust organization, then ix86_valid_target_attribute_p
> > called near
> > the end of the function is a problem. Because it in turn calls
> > ix86_valid_target_attribute_tree and this last function doesn't have a
> > similarly named
> > function in PPC code.
> > Also, once the attribute "vsx" is added, where is it used? I mean that in
> > the sense of
> > where is execution conditioned on the definition of say, the "sse2" string
> > in x86_64?
>
> You need to trigger what will the middle-end and backend do if you use
> explicit attribute((target ("vsx"))) on the function, so in the end it
> needs to do some parsing, create a TARGET_OPTION_NODE with the right option
> changes and put it to the function.
>
> Jakub
I'm still trying to understand why we need attribute((target("vsx"))).
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
The documentation for target(string) states that the purpose is to allow a
function to be
compiled with different target options than were specified on the command line.
Why would we
want the vector version of say sinf to be compiled for a different target than
the scalar sinf?
Bert.
Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
‐‐‐ Original Message ‐‐‐ On Tuesday, August 18, 2020 5:32 PM, Segher Boessenkool wrote: > On Tue, Aug 18, 2020 at 07:14:19PM +, GT wrote: > > > > That sounds like libmvec? > > > I still don't know what this is. > > > > Yes, it is libmvec. > > Now look at what GCC does to the code in Examples 1 and 2 at this link: > > https://sourceware.org/glibc/wiki/libmvec > > x86_64 added functionality to GCC so such code uses the new functions > > without the user > > having to re-write the loops and explicitly call the new functions. > > We are aiming to provide that same capability for PPC64 in GCC. > > Great! Please repost with what I already pointed out fixed, that > explanation added, and working links to the documentation? > Are you ok with the titles of the patch and this document? https://sourceware.org/glibc/wiki/HomePage?action=AttachFile=view=powerarchvectfuncabi.html Bert.
Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
‐‐‐ Original Message ‐‐‐ On Monday, August 17, 2020 5:28 PM, Segher Boessenkool wrote: > On Mon, Aug 17, 2020 at 05:44:46PM +, GT wrote: > > > > 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. > > > It is very very VERY hard to review this without being told the proper > > > setting here. > > > > What this is about: > > David Edelsohn wanted to have new library functions, one for each of these > > 6 single-precision functions: > > sinf, cosf, sincosf, expf, logf, powf; and these 6 double-precision > > functions: > > sin, cos, sincos, exp, log, and pow. > > For the single-precision functions, the corresponding new functions would > > compute 4 results > > simulatneously. For the double-precision functions, the new ones would > > compute 2 results > > simultaneously. > > x86_64 has already done something very similar so I thought I would adapt > > as much of their > > documentation and implementation as I could for PPC64. > > Let's start with that. Comments so far? > > That sounds like libmvec? > > I still don't know what this is. > Yes, it is libmvec. Now look at what GCC does to the code in Examples 1 and 2 at this link: https://sourceware.org/glibc/wiki/libmvec x86_64 added functionality to GCC so such code uses the new functions without the user having to re-write the loops and explicitly call the new functions. We are aiming to provide that same capability for PPC64 in GCC. Bert.
Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
‐‐‐ 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. > > It is very very VERY hard to review this without being told the proper > setting here. > What this is about: David Edelsohn wanted to have new library functions, one for each of these 6 single-precision functions: sinf, cosf, sincosf, expf, logf, powf; and these 6 double-precision functions: sin, cos, sincos, exp, log, and pow. For the single-precision functions, the corresponding new functions would compute 4 results simulatneously. For the double-precision functions, the new ones would compute 2 results simultaneously. x86_64 has already done something very similar so I thought I would adapt as much of their documentation and implementation as I could for PPC64. Let's start with that. Comments so far? Bert.
Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
‐‐‐ Original Message ‐‐‐
On Monday, August 10, 2020 2:07 PM, Jakub Jelinek wrote:
> On Mon, Aug 10, 2020 at 05:29:49PM +, GT wrote:
>
> > > For PowerPC, if all you want to support is b which requires VSX, then the
> > > right thing is for !TREE_PUBLIC functions return 0 if !TARGET_VSX and
> > > otherwise set vecsize_mangle to 'b' and in the end return 1, for exported
> > > functions always set it to 'b' (and in the end return 1).
> > > Then ensure that the 'b' variants of function definitions get target
> > > ("vsx")
> > > attribute added if !TARGET_VSX.
> >
> > So setting attribute "vsx" for 'b' variants of function definitions is what
> > should go in function rs6000_simd_clone_usable?
>
> No. That function should say if the particular clone ('b' in this case) is
> usable from some caller, and the answer for your 'b' is TARGET_VSX is
> required to be non-zero.
>
> The adjustment should go into the simd_clone_adjust target hook, see
> what ix86_simd_clone_adjust does (though, that one has more variants to
> handle).
I'm looking at ix86_simd_clone_adjust and also aarch64_simd_clone_adjust. The
latter is
much simpler and I see how I would add PPC attribute "vsx" similarly. If I was
to follow
the ix86_simd_clone_adjust organization, then ix86_valid_target_attribute_p
called near
the end of the function is a problem. Because it in turn calls
ix86_valid_target_attribute_tree and this last function doesn't have a
similarly named
function in PPC code.
Also, once the attribute "vsx" is added, where is it used? I mean that in the
sense of
where is execution conditioned on the definition of say, the "sse2" string in
x86_64?
Bert.
Re: [RFC PATCH v1 1/1] PPC64: Implement POWER Architecture Vector Function ABI.
‐‐‐ 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:
> > https://sourceware.org/glibc/wiki/Homepage?action=AttachFile=view=powerarchvectfuncabi.html
>
> Doesn't exist.
I can't tell what the issue is with the link as given above. But the one below
does actually open
the page for me.
https://sourceware.org/glibc/wiki/HomePage?action=AttachFile=view=powerarchvectfuncabi.html
>
> > - if (TARGET_VSX)
> > - {
> > -clonei->vecsize_mangle = 'b';
> >
> >
> > -ret = 1;
> >
> >
> > - }
> > - clonei->mask_mode = VOIDmode;
> > - switch (clonei->vecsize_mangle)
> > - {
> > - case 'b':
> > -clonei->vecsize_int = 128;
> >
> >
> > -clonei->vecsize_float = 128;
> >
> >
> > -break;
> >
> >
> > - case 'c':
> > -clonei->vecsize_int = 128;
> >
> >
> > -clonei->vecsize_float = 128;
> >
> >
>
> So what is this 'c' case here for?
>
I should have removed it. It will be deleted in the next version.
> > -break;
> >
> >
> > - default:
> > -gcc_unreachable ();
> >
> >
>
> If (!TARGET_VSX), this will abort (as you only set vecsize_mangle to 'b'
> if TARGET_VSX, otherwise nothing sets it (so it remains 0).
>
> The way this works is that the caller calls the target hook with 0
> as last argument, and the hook either returns 0 (means not supported at
> all), or returns number of supported variants and provides the first one.
> If more than one are supported, the caller will keep iterating on those.
> E.g. on x86, we support 4 modes (b, c, d, e) for exported functions and
> for non-exported ones just choose a single one based on the ISA, because in
> that case it is not a matter of ABI.
>
> For PowerPC, if all you want to support is b which requires VSX, then the
> right thing is for !TREE_PUBLIC functions return 0 if !TARGET_VSX and
> otherwise set vecsize_mangle to 'b' and in the end return 1, for exported
> functions always set it to 'b' (and in the end return 1).
> Then ensure that the 'b' variants of function definitions get target ("vsx")
> attribute added if !TARGET_VSX.
>
So setting attribute "vsx" for 'b' variants of function definitions is what
should go in function rs6000_simd_clone_usable?
Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
‐‐‐ Original Message ‐‐‐ On Sunday, February 16, 2020 7:06 PM, Segher Boessenkool wrote: > On Sat, Feb 15, 2020 at 05:22:09PM +, GT wrote: > > I have not been able to configure protonmail for either git imap-send or > > send-email. > > Do you use git format-patch? You should, as the manual pages for both > git imap-send and git send-email explain. > > > Will try pasting the .patch inline as plain text and see if that works. > > That doesn't work, unless you take extreme care. It is fine for showing > small snippets, but it does not result in patches people can apply. > I have more patches I'd like to post and I have been unable to find an alternative to sending them as binary attachments. 1. The only system I have access to is a Windows 10 machine. I am not allowed to modify it in any way. So I can't install cygwin (or any other software), if having that would have solved my issues. 2. I am creating the patches on a VM in one of the clouds IBM makes available for POWER software development. To access the VM the only option I have thus far is to login using Openstack from a browser. Then open a console in the interface. To get patches out of the VM, I push them onto Github. Then download them onto the Windows PC to send as email attachments. 3. On the VM git imap-send and send-email are not usable for me at the moment. Gmail now requires 2-factor authentication for them. And that in turn requires a cell phone. I can't say when I will have a new phone. Anyone have ideas on how to avoid the binary attachements? Bert.
