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 +0000, 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 +0000, 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 +0000, 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 +0000, 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 +0000, 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 +0000, 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.
Re: GLIBC libmvec status
‐‐‐ 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 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 libmvec functions would have > > to > > work on Power ISA v2.06 HW too. But half of the functions do use v2.07 > > instructions now. > > Ah, I see. Well, then language such as "VSX defined at least at the level of > PowerISA v2.07" would be appropriate. We want to define a minimum subset > without > further implied constraint. (Higher levels can be handled with ifunc without > needing to reference this in the ABI, as previously discussed.) > Changed description of 'b' ISA to exactly the quoted sentence above. Bert.
Re: GLIBC libmvec status
‐‐‐ 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 important part, as it matters for the ABI).
What is in omp-simd-clone.c? What is missing from the vectorizer? My assumption
was that
the implementation of vector function masking was complete, but no test was
created to
verify the functionality.
> A testcase could
> be something along the lines of
> #pragma omp declare simd
> int foo (int, int);
>
> void
> bar (int *a, int *b, int *c)
> {
> #pragma omp simd
> for (int i = 0; i < 1024; i++)
> {
> int d = b[i], e = c[i], f;
> if (b[i] < 20)
> f = foo (d, e);
> else
> f = d + e;
> }
> }
I thought the test would be more like:
#pragma omp declare simd
int
foo (int *x, int *y)
{
*y = *x + 2;
}
void
bar (int *a, float *b, float *c)
{
#pragma omp simd
for (int i = 0; i < 1024; i++)
{
int d = b[i], e = c[i], f;
if ( i % 2)
f = foo (d, e);
}
}
The point being that only items at odd indices are updated. That would require
masking to avoid altering items at even indices.
Bert.
Re: GLIBC libmvec status
‐‐‐ 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 having manually created
> > vector
>
> The feature made it into the OpenMP standard (already OpenMP 4.0) and so got
> implemented as part of the OpenMP 4.0 implementation.
>
> > versions of sin, cos and other libmvec functions, I'm wondering how GCC is
> > able to
> > autovectorize a non-trivial user defined function.
>
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 letting GCC inline such functions and
having
the loop autovectorizer handle the resulting code?
> There are various tests that cover it, look e.g. at tests that require
> vect_simd_clones
> effective target (e.g. in gcc/testsuite//{vect,gomp}/ and
> libgomp/testsuite//).
>
Sorry, I can't identify any test that ensures a masked vector function variant
produces
expected results. I'll check again but I need more help here.
Bert.
Re: GLIBC libmvec status
‐‐‐ 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 better off warning and > > ignoring the directive, leaving the code in scalar form? > > Depends on the exact code, I think sometimes it will be just fine and will > allow vectorizing something that really couldn't be otherwise. > Isn't it better to leave it for the user to decide? > They can always ask for it not to be generated (add notinbranch) if it isn't > worthwhile. > I'm trying to understand what the x86_64 implementation does w.r.t. masked versions of user defined functions. I haven't found any test under directory testsuite which verifies that compiler-generated versions (from inbranch being specified) produce expected results. Which raises the question: what use-case motivated allowing the compiler to auto-vectorize user defined functions? From having manually created vector versions of sin, cos and other libmvec functions, I'm wondering how GCC is able to autovectorize a non-trivial user defined function. Any pointers to relevant tests and documentation will be really appreciated. Thanks. Bert.
Re: GLIBC libmvec status
‐‐‐ 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://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? > 1. Reference to 'c' ABI deleted. 2. In final paragraph of section "Vector Function ABI Overview", removed reference to ELFv2 specification. Replaced with reference to OpenPOWER IBM Power ISA v2.07. 3. Cleaned up display of angle brackets in section "Vector Function Name Mangling". Question: 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". Bert.
Re: GLIBC libmvec status
‐‐‐ 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 provided names and links to respective ABI documents but no longer
explicitly refer to ELF version.
> (2) "Vector Length" should remove bullet 3, strike the word
> "nonhomogeneous" in bullet 4, and strike the parenthetical clause in
> bullet 4.
> (3) "Ordering of Vector Arguments" should remove the example involving
> homogeneous aggregates.
>
Done.
> It also occurs to me that for bullets 4 and 5 in "Vector Length", the
> CDT should be long long, not int, since we pass aggregates in pieces in
> 64-bit registers and/or chunks of memory.
>
That determination of Vector Length is common for all architectures and is
implemented in function simd_clone_compute_base_data_type. If we do really
need PPC64 to be different, we'll have to allow the function to be replaced
by architecture-specific versions. Before we do that, do you have
an example of code which ends up with incorrect vectorization with the
existing CDT of int?
> Other small bugs:
> - Bullet 4 says "the CDT determine by a) or b) above", but the referents
> should be "(1) or (2)" instead.
> - First line of "Compiler generated variants of vector functions" has
> a typo ("umasked").
>
Done.
The updated document is at:
https://sourceware.org/glibc/wiki/HomePage?action=AttachFile=view=powerarchvectfuncabi.html
Re: GLIBC libmvec status
‐‐‐ 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 Vector > > > Function ABI page? My first quick attempt resulted in the html tags being > > > rendered on the > > > page verbatim. > > > > Sure! > > Let me know when you update the wiki and I'll send the patches to > > libc-alpha. > > > > Meanwhile, let me clarify another point... > > > > Bert, Bill, Segher, > > > > In the GCC discussion, Jakub pointed out [1] the new vector ABI targets > > ELFv2, > > but there is nothing preventing it from being used on powerpc64-linux or > > powerpc-linux. > > On the other hand, the glibc patches enable libmvec on powerpc64le and > > powerpc64. > > > > IMHO, regardless of the decision, GCC and glibc should be in sync. > > > > Bert, did you get a chance to test the GCC patches on powerpc64-linux? > > I've been testing the glibc patches and they work fine, but they require > > POWER8 (the vector ABI also requires P8). > > > > Bill, Segher, > > What do you think is the best solution from the GCC point of view? > > As I just wrote on gcc-patches, we should disable libmvec for powerpc64. > The vector ABI as written isn't compatible with ELFv1. We would need > a modified ABI that doesn't allow homogeneous aggregates of vectors to > be returned in registers in order to support ELFv1. I do not believe > that is worth pursuing until and unless there is demand for it (which > I do not expect). > 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 sysdeps/powerpc/powerpc64/fpu. Do we need to create a new directory as sysdeps/powerpc/powerpc64/powerpc64le/fpu and into it move the aforementioned files? 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 expect that TARGET_VSX, TARGET_P8_VECTOR or TARGET_P9_VECTOR are not specific enough. Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
‐‐‐ 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" and providing the rules for vectorizing > functions into calls to libmvec. I tend to agree that it is a bit more like > API than ABI, but we are just fitting into existing frameworks and using the > same nomenclature. > > The ABI that Bert has produced for us is available at > https://sourceware.org/glibc/wiki/HomePage?action=AttachFile=view=powerarchvectfuncabi.html. > > It is based on a similar document for x86. I believe this is the most up-to- > date version: > https://software.intel.com/sites/default/files/managed/b4/c8/Intel-Vector-Function-ABI.pdf > > There's been ongoing work in the same area for AArch64, with the most recent > version available here, I believe: > https://developer.arm.com/docs/101129/latest > > I am not certain of the completion status of the AArch64 implementation. > The libmvec implementation for Intel has been around for a long time. > > Hope that at least starts to help, > Bill Additionally, here is GLIBC's introduction of libmvec: https://sourceware.org/glibc/wiki/libmvec Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
‐‐‐ 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 specified in > > ISA v2.07, > > I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio? > > No, I don't think that's the right call. We want to leverage ISA 3.0 > instructionsin vector implementations when they are available, so we > need the 'c' ABI for that purpose. In future we are likely to add a > 'd' ABI for a future processor if it adds more vector capability. So > emitting both and letting the vectorized callers choose, as Jakub > suggests, seems like the right way to go. This is true even if the > current implementations are identical (i.e., don't exploit any ISA > 3.0 instructions). > Because of the issue at https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01171.html, I am coming back to whether or not to include VSX extensions for ISA 3.0 in the Vector Function ABI Specification. If we retain 'c' in the ABI Spec., then GCC will expect libmvec functions such as _ZGVcN2v_sin. The changes made to GLIBC for POWER libmvec don't have these functions with == 'c'. Only those with == 'b' have been implemented. So we have to do either of: 1. Create all those 'c' variants in GLIBC libmvec, even though they will be identical to the existing 'b' versions. 2. Remove all references to 'c' in the ABI Specification, and leave GCC expecting to find only 'b' variants in libmvec. If/when it becomes necessary to have 'c' variants of functions, then a new version of the Vector Function ABI document will be created. And GLIBC and GCC modifications to comply with that new ABI will be made then. Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
‐‐‐ 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 vector variants will be created by
> > the compiler. And that it will be up to the caller of vectorized
> > functions to select the preferred version ('b' or 'c' are the only
> > choices presently).
> >
>
> A reminder, "all" needs to be a particular fixed set that will not be
> expanded in future versions of the ABI, so that a glibc installed now
> continues to work with future compilers (rather than a future compiler
> wrongly taking a pragma / attribute in existing glibc headers as meaning
> some future vector ISA variant, unknown when that glibc header was
> written, is available).
What more needs to be done other than documenting the GLIBC and GCC versions for
which 'b' and 'c' vector versions are available? It is how x86_64 explained
the differences between Examples 1 and 2 at
https://sourceware.org/glibc/wiki/libmvec
Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
‐‐‐ 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 specified in
> > ISA v2.07,
> > I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio?
>
> No, I don't think that's the right call. We want to leverage ISA 3.0
> instructionsin vector implementations when they are available, so we
> need the 'c' ABI for that purpose. In future we are likely to add a
> 'd' ABI for a future processor if it adds more vector capability. So
> emitting both and letting the vectorized callers choose, as Jakub
> suggests, seems like the right way to go. This is true even if the
> current implementations are identical (i.e., don't exploit any ISA
> 3.0 instructions).
>
Here are proposed modifications:
1. In the Vector Function ABI document, under section "Vector Function Name
Mangling",
state that all vector variants will be created by the compiler. And that
it will
be up to the caller of vectorized functions to select the preferred version
('b' or 'c'
are the only choices presently).
2. Change rs6000_simd_clone_usable so that it more closely resembles
ix86_simd_clone_usable.
The switch statement in that function will add a clause for 'c' to the existing
one for 'b'.
I'm not sure what to test for in the 'c' clause. In x86_64, they have
TARGET_SSE2, TARGET_AVX,
TARGET_AVX2 and TARGET_AVX512. PPC64 has only TARGET_VSX as best I can
determine. There are
macros PPC_FEATURE2_ARCH_2_07 and PPC_FEATURE2_ARCH_3_00 in ppc-auxv.h. Can we
use these 2
macros where x86_64 uses the macros with prefix TARGET_ ?
Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
‐‐‐ 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: > > > > > > > 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. > > > > > > > > So shouldn't the callback set target attribute (on definitions) to > > > > "vsx"? > > > > > > I did consider doing something similar to aarch64_simd_clone_adjust. But > > > the reason > > > Aarch64 has a new attribute aarch64_vector_pcs is that they implemented a > > > modified > > > function calling sequence for vector functions. PPC64 vector functions > > > use the existing > > > function calling sequence spelled out in the 64-bit ELFv2 ABI. So with no > > > new attribute > > > here, the function body ends up empty. > > > Have I missed something crucial? > > > > I haven't seen anything in the patch that would only enable it for ELFv2, > > The idea is that the vector functionality defined in the ABI is guaranteed > only > on systems that implement the ELFv2 ABI. It's possible that the functionality > also > works on ELFv1 Big-Endian PPC64. I'll check if that's the case. If so, then > the ABI > will need modification. > > > and while powerpc64le-linux probably assumes TARGET_VSX unconditionally > > (haven't verified), powerpc64-linux or powerpc-linux certainly doesn't. > > The last function in the patch, rs6000_simd_clone_usable, returns a value > that will > disable use of vector variants if TARGET_VSX is undefined. > > > And it is just fine to have the ABI for those pass/return vectors in VSX > > registers too, after all, it won't be used if the vectorized caller isn't > > TARGET_VSX, > > Don't quite understand the comment here. Are you stating the possibility of > a system that has VSX hardware but does not define macro TARGET_VSX? > > > the definitions of the declare simd functions could be compiled > > with different ISA options. > > Do you mean the 'b' vs 'c' in the ABI's vector function name mangling? > > > And, if the ABI sais that the 'b' stuff assumes > > certain ISA extensions, if the declare simd function definition is compiled > > with e.g. -mno-vsx -mno-altivec, it would either not be able to get the > > arguments/return values at all, or wouldn't benefit from the ISA guarantees > > the ABI gives to it. > > Not sure if you expect a response here. > > > BTW, in the ABI document there isn't just 'b', but also 'c' ABI, it is > > unclear if one needs to always emit both (e.g. like on x86 we emit 'b', 'c', > > 'd' and 'e') and then let the vectorized callers choose based on what ISA > > options it is compiled with. > > 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 specified in ISA > v2.07, > I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio? > Jakub: Are there any specific changes you would like made to the patch? Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
‐‐‐ 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 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. > > > > > > So shouldn't the callback set target attribute (on definitions) to "vsx"? > > > > I did consider doing something similar to aarch64_simd_clone_adjust. But > > the reason > > Aarch64 has a new attribute aarch64_vector_pcs is that they implemented a > > modified > > function calling sequence for vector functions. PPC64 vector functions use > > the existing > > function calling sequence spelled out in the 64-bit ELFv2 ABI. So with no > > new attribute > > here, the function body ends up empty. > > Have I missed something crucial? > > I haven't seen anything in the patch that would only enable it for ELFv2, > The idea is that the vector functionality defined in the ABI is guaranteed only on systems that implement the ELFv2 ABI. It's possible that the functionality also works on ELFv1 Big-Endian PPC64. I'll check if that's the case. If so, then the ABI will need modification. > and while powerpc64le-linux probably assumes TARGET_VSX unconditionally > (haven't verified), powerpc64-linux or powerpc-linux certainly doesn't. > The last function in the patch, rs6000_simd_clone_usable, returns a value that will disable use of vector variants if TARGET_VSX is undefined. > And it is just fine to have the ABI for those pass/return vectors in VSX > registers too, after all, it won't be used if the vectorized caller isn't > TARGET_VSX, Don't quite understand the comment here. Are you stating the possibility of a system that has VSX hardware but does not define macro TARGET_VSX? > the definitions of the declare simd functions could be compiled > with different ISA options. Do you mean the 'b' vs 'c' in the ABI's vector function name mangling? > And, if the ABI sais that the 'b' stuff assumes > certain ISA extensions, if the declare simd function definition is compiled > with e.g. -mno-vsx -mno-altivec, it would either not be able to get the > arguments/return values at all, or wouldn't benefit from the ISA guarantees > the ABI gives to it. > Not sure if you expect a response here. > BTW, in the ABI document there isn't just 'b', but also 'c' ABI, it is > unclear if one needs to always emit both (e.g. like on x86 we emit 'b', 'c', > 'd' and 'e') and then let the vectorized callers choose based on what ISA > options it is compiled with. > 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 specified in ISA v2.07, I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio? Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
‐‐‐ 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 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. > > Please Cc: the rs6000 maintainers on rs6000 patches, you will get a > reply faster, and more reliably. > File MAINTAINERS has you, David Edelsohn and Aldy Hernandez listed as maintainers of various rs6000 aspects. Is that who you say I should "Cc:" or is there a separate mailing list for rs6000? > Please don't use binary attachments, it takes effort to reply to those. > I have not been able to configure protonmail for either git imap-send or send-email. Will try pasting the .patch inline as plain text and see if that works. Bert.
Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
‐‐‐ 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 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. > > So shouldn't the callback set target attribute (on definitions) to "vsx"? > I did consider doing something similar to aarch64_simd_clone_adjust. But the reason Aarch64 has a new attribute aarch64_vector_pcs is that they implemented a modified function calling sequence for vector functions. PPC64 vector functions use the existing function calling sequence spelled out in the 64-bit ELFv2 ABI. So with no new attribute here, the function body ends up empty. Have I missed something crucial? Bert.
[RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.
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. 0001-PPC64-Implement-POWER-Architecure-Vector-Function-AB.patch Description: Binary data
