| Message ID | a86c2bf8-fc4c-4c7d-97a4-d16cd433ff85@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | rs6000, document built-ins vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros | expand |
Hi Carl, on 2024/7/27 06:56, Carl Love wrote: > GCC maintainers: > > Per a report from a user, the existing vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins are not documented in the GCC documentation file. > > The following patch adds missing documentation for the vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins. > > Please let me know if the patch is acceptable for mainline. Thanks. > > Carl > > ------------------------------------------------------------------- > rs6000, document built-ins vec_test_lsbb_all_ones and vec_test_lsbb_all_zeros > > Add documentation for the Power 10 built-ins vec_test_lsbb_all_ones > and vec_test_lsbb_all_zeros. The vec_test_lsbb_all_ones built-in > returns 1 if the least significant bit in each byte is a 1, returns > 0 otherwise. Similarly, vec_test_lsbb_all_zeros returns a 1 if > the least significant bit in each byte is a zero and 0 otherwise. > > The test cases for the built-ins are in files: > gcc/testsuite/gcc.target/powerpc/lsbb.c > gcc/testsuite/gcc.target/powerpc/lsbb-runnable.c > > > gcc/ChangeLog: > * doc/extend.texi (vec_test_lsbb_all_ones, > vec_test_lsbb_all_zeros): Add documentation for the > existing built-ins. > --- > gcc/doc/extend.texi | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index 83ff168faf6..96e41c9a905 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > @@ -23240,6 +23240,21 @@ signed long long will sign extend the rightmost byte of each doubleword. > The following additional built-in functions are also available for the > PowerPC family of processors, starting with ISA 3.1 (@option{-mcpu=power10}): > > +@smallexample > +@exdent int vec_test_lsbb_all_ones (vector char); I think we need to specify "unsigned" char explicitly since we don't actually allow vector "signed" char as the below testing shows: int foo11 (vector signed char va) { return vec_test_lsbb_all_ones (va); } <source>:17:3: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_xvtlsbb_all_ones' 17 | return vec_test_lsbb_all_ones (va); Now we make these two bifs as overload, but there is only one instance respectively, either is with "vector unsigned char" as argument type, but the corresponding instance prototype in builtin table is with "vector signed char". It's inconsistent and weird, I think we can just update the prototype in builtin table with "vector unsigned char" and remove the entries in overload table. It can be a follow up patch. > +@end smallexample > +@findex vec_test_lsbb_all_ones > + > +The builtin @code{vec_test_lsbb_all_ones} returns 1 if the least significant > +bit in each byte is a one. It returns a zero otherwise. May be better to use the wording "equal to 1" referred from ISA and "returns 0" matches the preceding "returns 1", like: “... in each byte is equal to 1. It returns 0 otherwise.” > + > +@smallexample > +@exdent int vec_test_lsbb_all_zeros (vector char); > +@end smallexample > +@findex vec_test_lsbb_all_zeros > + > +The builtin @code{vec_test_lsbb_all_zeros} returns 1 if the least significant > +bit in each byte is a zero. It returns a zero otherwise. Likewise, "... in each byte is equal to 0. It returns 0 otherwise." OK with these nits tweaked, thanks! BR, Kewen
Kewen: On 7/31/24 2:12 AM, Kewen.Lin wrote: > Hi Carl, > > on 2024/7/27 06:56, Carl Love wrote: >> GCC maintainers: >> >> Per a report from a user, the existing vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins are not documented in the GCC documentation file. >> >> The following patch adds missing documentation for the vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins. >> >> Please let me know if the patch is acceptable for mainline. Thanks. >> >> Carl >> >> ------------------------------------------------------------------- >> rs6000, document built-ins vec_test_lsbb_all_ones and vec_test_lsbb_all_zeros >> >> Add documentation for the Power 10 built-ins vec_test_lsbb_all_ones >> and vec_test_lsbb_all_zeros. The vec_test_lsbb_all_ones built-in >> returns 1 if the least significant bit in each byte is a 1, returns >> 0 otherwise. Similarly, vec_test_lsbb_all_zeros returns a 1 if >> the least significant bit in each byte is a zero and 0 otherwise. >> >> The test cases for the built-ins are in files: >> gcc/testsuite/gcc.target/powerpc/lsbb.c >> gcc/testsuite/gcc.target/powerpc/lsbb-runnable.c >> >> >> gcc/ChangeLog: >> * doc/extend.texi (vec_test_lsbb_all_ones, >> vec_test_lsbb_all_zeros): Add documentation for the >> existing built-ins. >> --- >> gcc/doc/extend.texi | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi >> index 83ff168faf6..96e41c9a905 100644 >> --- a/gcc/doc/extend.texi >> +++ b/gcc/doc/extend.texi >> @@ -23240,6 +23240,21 @@ signed long long will sign extend the rightmost byte of each doubleword. >> The following additional built-in functions are also available for the >> PowerPC family of processors, starting with ISA 3.1 (@option{-mcpu=power10}): >> >> +@smallexample >> +@exdent int vec_test_lsbb_all_ones (vector char); > I think we need to specify "unsigned" char explicitly since we don't actually > allow vector "signed" char as the below testing shows: > > int foo11 (vector signed char va) > { > return vec_test_lsbb_all_ones (va); > } > > <source>:17:3: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_xvtlsbb_all_ones' > 17 | return vec_test_lsbb_all_ones (va); > > > Now we make these two bifs as overload, but there is only one instance respectively, Yes, I noticed that the built-ins were defined as overloaded but only had one definition. Did seem odd to me. > either is with "vector unsigned char" as argument type, but the corresponding instance > prototype in builtin table is with "vector signed char". It's inconsistent and weird, > I think we can just update the prototype in builtin table with "vector unsigned char" > and remove the entries in overload table. It can be a follow up patch. I didn't notice that it was signed in the instance prototype but unsigned in the overloaded definition. That is definitely inconsistent. That said, should we just go ahead and support both signed and unsigned argument versions of the all ones and all zeros built-ins? For example [VEC_TEST_LSBB_ALL_ONES, vec_test_lsbb_all_ones, __builtin_vec_xvtlsbb_all_ones] signed int __builtin_vec_xvtlsbb_all_ones (vsc); XVTLSBB_ONES LSBB_ALL_ONES_VSC signed int __builtin_vec_xvtlsbb_all_ones (vuc); XVTLSBB_ONES LSBB_ALL_ONES_VUC I tried this with the testcase, I borrowed from you and extended: int foo11 (vector char va) <- compiles fine { return vec_test_lsbb_all_ones (va); } int sfoo11 (vector signed char sva) <- currently fails to compile without change to overloaded def, compiles with { additional overloaded definition. return vec_test_lsbb_all_ones (sva); } int ufoo11 (vector unsigned char uva) <- compiles fine { return vec_test_lsbb_all_ones (uva); } I did a quick test to see that the testcase does compile. We would need to add testcases to lsbb.c and lsbb-runnable.c and then update the documentation to say both are supported. Thoughts on expanding the scope of the patch from just documentation to adding additional overloaded cases and updating the documentation? > >> +@end smallexample >> +@findex vec_test_lsbb_all_ones >> + >> +The builtin @code{vec_test_lsbb_all_ones} returns 1 if the least significant >> +bit in each byte is a one. It returns a zero otherwise. > May be better to use the wording "equal to 1" referred from ISA and "returns 0" > matches the preceding "returns 1", like: > > “... in each byte is equal to 1. It returns 0 otherwise.” Changed. >> + >> +@smallexample >> +@exdent int vec_test_lsbb_all_zeros (vector char); >> +@end smallexample >> +@findex vec_test_lsbb_all_zeros >> + >> +The builtin @code{vec_test_lsbb_all_zeros} returns 1 if the least significant >> +bit in each byte is a zero. It returns a zero otherwise. > Likewise, "... in each byte is equal to 0. It returns 0 otherwise." Changed. Carl
on 2024/8/1 01:52, Carl Love wrote: > Kewen: > > On 7/31/24 2:12 AM, Kewen.Lin wrote: >> Hi Carl, >> >> on 2024/7/27 06:56, Carl Love wrote: >>> GCC maintainers: >>> >>> Per a report from a user, the existing vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins are not documented in the GCC documentation file. >>> >>> The following patch adds missing documentation for the vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins. >>> >>> Please let me know if the patch is acceptable for mainline. Thanks. >>> >>> Carl >>> >>> ------------------------------------------------------------------- >>> rs6000, document built-ins vec_test_lsbb_all_ones and vec_test_lsbb_all_zeros >>> >>> Add documentation for the Power 10 built-ins vec_test_lsbb_all_ones >>> and vec_test_lsbb_all_zeros. The vec_test_lsbb_all_ones built-in >>> returns 1 if the least significant bit in each byte is a 1, returns >>> 0 otherwise. Similarly, vec_test_lsbb_all_zeros returns a 1 if >>> the least significant bit in each byte is a zero and 0 otherwise. >>> >>> The test cases for the built-ins are in files: >>> gcc/testsuite/gcc.target/powerpc/lsbb.c >>> gcc/testsuite/gcc.target/powerpc/lsbb-runnable.c >>> >>> >>> gcc/ChangeLog: >>> * doc/extend.texi (vec_test_lsbb_all_ones, >>> vec_test_lsbb_all_zeros): Add documentation for the >>> existing built-ins. >>> --- >>> gcc/doc/extend.texi | 15 +++++++++++++++ >>> 1 file changed, 15 insertions(+) >>> >>> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi >>> index 83ff168faf6..96e41c9a905 100644 >>> --- a/gcc/doc/extend.texi >>> +++ b/gcc/doc/extend.texi >>> @@ -23240,6 +23240,21 @@ signed long long will sign extend the rightmost byte of each doubleword. >>> The following additional built-in functions are also available for the >>> PowerPC family of processors, starting with ISA 3.1 (@option{-mcpu=power10}): >>> >>> +@smallexample >>> +@exdent int vec_test_lsbb_all_ones (vector char); >> I think we need to specify "unsigned" char explicitly since we don't actually >> allow vector "signed" char as the below testing shows: >> >> int foo11 (vector signed char va) >> { >> return vec_test_lsbb_all_ones (va); >> } >> >> <source>:17:3: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_xvtlsbb_all_ones' >> 17 | return vec_test_lsbb_all_ones (va); >> >> >> Now we make these two bifs as overload, but there is only one instance respectively, > Yes, I noticed that the built-ins were defined as overloaded but only had one definition. Did seem odd to me. > >> either is with "vector unsigned char" as argument type, but the corresponding instance >> prototype in builtin table is with "vector signed char". It's inconsistent and weird, >> I think we can just update the prototype in builtin table with "vector unsigned char" >> and remove the entries in overload table. It can be a follow up patch. > > I didn't notice that it was signed in the instance prototype but unsigned in the overloaded definition. That is definitely inconsistent. > > That said, should we just go ahead and support both signed and unsigned argument versions of the all ones and all zeros built-ins? Good question, I thought about that but found openxl only supports the unsigned version so I felt it's probably better to keep consistent with it. But I'm fine for either, if we decide to extend it to cover both signed and unsigned, we should notify openxl team to extend it as well. openxl doc links: https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-ones https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-zeros BR, Kewen > > For example > > [VEC_TEST_LSBB_ALL_ONES, vec_test_lsbb_all_ones, __builtin_vec_xvtlsbb_all_ones] > signed int __builtin_vec_xvtlsbb_all_ones (vsc); > XVTLSBB_ONES LSBB_ALL_ONES_VSC > signed int __builtin_vec_xvtlsbb_all_ones (vuc); > XVTLSBB_ONES LSBB_ALL_ONES_VUC > > I tried this with the testcase, I borrowed from you and extended: > > int foo11 (vector char va) <- compiles fine > { > return vec_test_lsbb_all_ones (va); > } > > int sfoo11 (vector signed char sva) <- currently fails to compile without change to overloaded def, compiles with > { additional overloaded definition. > return vec_test_lsbb_all_ones (sva); > } > > int ufoo11 (vector unsigned char uva) <- compiles fine > { > return vec_test_lsbb_all_ones (uva); > } > > I did a quick test to see that the testcase does compile. We would need to add testcases to lsbb.c and lsbb-runnable.c and then update > the documentation to say both are supported. > > Thoughts on expanding the scope of the patch from just documentation to adding additional overloaded cases and updating the documentation? > >> >>> +@end smallexample >>> +@findex vec_test_lsbb_all_ones >>> + >>> +The builtin @code{vec_test_lsbb_all_ones} returns 1 if the least significant >>> +bit in each byte is a one. It returns a zero otherwise. >> May be better to use the wording "equal to 1" referred from ISA and "returns 0" >> matches the preceding "returns 1", like: >> >> “... in each byte is equal to 1. It returns 0 otherwise.” > > Changed. >>> + >>> +@smallexample >>> +@exdent int vec_test_lsbb_all_zeros (vector char); >>> +@end smallexample >>> +@findex vec_test_lsbb_all_zeros >>> + >>> +The builtin @code{vec_test_lsbb_all_zeros} returns 1 if the least significant >>> +bit in each byte is a zero. It returns a zero otherwise. >> Likewise, "... in each byte is equal to 0. It returns 0 otherwise." > > Changed. > > Carl >
On 7/31/24 10:21 PM, Kewen.Lin wrote: > on 2024/8/1 01:52, Carl Love wrote: >> Yes, I noticed that the built-ins were defined as overloaded but only had one definition. Did seem odd to me. >> >>> either is with "vector unsigned char" as argument type, but the corresponding instance >>> prototype in builtin table is with "vector signed char". It's inconsistent and weird, >>> I think we can just update the prototype in builtin table with "vector unsigned char" >>> and remove the entries in overload table. It can be a follow up patch. >> >> I didn't notice that it was signed in the instance prototype but unsigned in the overloaded definition. That is definitely inconsistent. >> >> That said, should we just go ahead and support both signed and unsigned argument versions of the all ones and all zeros built-ins? > > Good question, I thought about that but found openxl only supports the unsigned version > so I felt it's probably better to keep consistent with it. But I'm fine for either, if > we decide to extend it to cover both signed and unsigned, we should notify openxl team > to extend it as well. > > openxl doc links: > > https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-ones > https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-zeros If it makes sense to support vector signed char rather than only the vector unsigned char, then I'm fine adding support for it. It almost seems since we tried adding an overload for it, that that was our intention (to support both signed and unsigned) and we just had a bug so only unsigned was supported? CC'ing Steve since he noticed the missing documentation when we was trying to use the built-ins. Steve, do you see a need to also support vector signed char with these built-ins? Peter
on 2024/8/3 05:48, Peter Bergner wrote: > On 7/31/24 10:21 PM, Kewen.Lin wrote: >> on 2024/8/1 01:52, Carl Love wrote: >>> Yes, I noticed that the built-ins were defined as overloaded but only had one definition. Did seem odd to me. >>> >>>> either is with "vector unsigned char" as argument type, but the corresponding instance >>>> prototype in builtin table is with "vector signed char". It's inconsistent and weird, >>>> I think we can just update the prototype in builtin table with "vector unsigned char" >>>> and remove the entries in overload table. It can be a follow up patch. >>> >>> I didn't notice that it was signed in the instance prototype but unsigned in the overloaded definition. That is definitely inconsistent. >>> >>> That said, should we just go ahead and support both signed and unsigned argument versions of the all ones and all zeros built-ins? >> >> Good question, I thought about that but found openxl only supports the unsigned version >> so I felt it's probably better to keep consistent with it. But I'm fine for either, if >> we decide to extend it to cover both signed and unsigned, we should notify openxl team >> to extend it as well. >> >> openxl doc links: >> >> https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-ones >> https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-zeros > > If it makes sense to support vector signed char rather than only the vector unsigned char, > then I'm fine adding support for it. It almost seems since we tried adding an overload > for it, that that was our intention (to support both signed and unsigned) and we just > had a bug so only unsigned was supported? Good question but I'm not sure, it could be an oversight without adding one more instance for overloading, or adopting some useless code (only for overloading) for a single instance. I found it's introduced by r11-2437-gcf5d0fc2d1adcd, CC'ed Will as he contributed this. BR, Kewen > > CC'ing Steve since he noticed the missing documentation when we was trying to > use the built-ins. Steve, do you see a need to also support vector signed char > with these built-ins? > > Peter > >
Looking at the latest version of the Power Vector Intrinsic Programming Reference (Revision 2.0.0_prd, Bill slipped this to me for review), I see that vec_test_lsbb_all_ones vec_test_lsbb_all_zeros both specify vector unsigned char, only. On Mon, Aug 5, 2024 at 1:15 AM Kewen.Lin <linkw@linux.ibm.com> wrote: > on 2024/8/3 05:48, Peter Bergner wrote: > > On 7/31/24 10:21 PM, Kewen.Lin wrote: > >> on 2024/8/1 01:52, Carl Love wrote: > >>> Yes, I noticed that the built-ins were defined as overloaded but only > had one definition. Did seem odd to me. > >>> > >>>> either is with "vector unsigned char" as argument type, but the > corresponding instance > >>>> prototype in builtin table is with "vector signed char". It's > inconsistent and weird, > >>>> I think we can just update the prototype in builtin table with > "vector unsigned char" > >>>> and remove the entries in overload table. It can be a follow up > patch. > >>> > >>> I didn't notice that it was signed in the instance prototype but > unsigned in the overloaded definition. That is definitely inconsistent. > >>> > >>> That said, should we just go ahead and support both signed and > unsigned argument versions of the all ones and all zeros built-ins? > >> > >> Good question, I thought about that but found openxl only supports the > unsigned version > >> so I felt it's probably better to keep consistent with it. But I'm > fine for either, if > >> we decide to extend it to cover both signed and unsigned, we should > notify openxl team > >> to extend it as well. > >> > >> openxl doc links: > >> > >> > https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-ones > >> > https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-zeros > > > > If it makes sense to support vector signed char rather than only the > vector unsigned char, > > then I'm fine adding support for it. It almost seems since we tried > adding an overload > > for it, that that was our intention (to support both signed and > unsigned) and we just > > had a bug so only unsigned was supported? > > Good question but I'm not sure, it could be an oversight without adding > one more instance > for overloading, or adopting some useless code (only for overloading) for > a single instance. > I found it's introduced by r11-2437-gcf5d0fc2d1adcd, CC'ed Will as he > contributed this. > > BR, > Kewen > > > > > CC'ing Steve since he noticed the missing documentation when we was > trying to > > use the built-ins. Steve, do you see a need to also support vector > signed char > > with these built-ins? > > > > Peter > > > > > >
Steve: Agreed the documentation only specifies unsigned char argument for the two built-ins. Do you think we should add support signed char arguments in addition to the documented unsigned char arguments? Do you see any situations where a user might want to to have both signed and unsigned char arguments for the two built-ins? Thanks. Carl On 8/5/24 2:12 PM, Steven Munroe wrote: > Looking at the latest version of the Power Vector Intrinsic > Programming Reference (Revision 2. 0. 0_prd, Bill slipped this to me > for review), I see that vec_test_lsbb_all_ones vec_test_lsbb_all_zeros > both specify vector unsigned char, only. On > > Looking at the latest version of the Power Vector Intrinsic > Programming Reference (Revision 2.0.0_prd, Bill slipped this to me for > review), I see that > > > vec_test_lsbb_all_ones > > > vec_test_lsbb_all_zeros > > both specify vector unsigned char, only. > > On Mon, Aug 5, 2024 at 1:15 AM Kewen.Lin <linkw@linux.ibm.com> wrote: > > on 2024/8/3 05:48, Peter Bergner wrote: > > On 7/31/24 10:21 PM, Kewen.Lin wrote: > >> on 2024/8/1 01:52, Carl Love wrote: > >>> Yes, I noticed that the built-ins were defined as overloaded > but only had one definition. Did seem odd to me. > >>> > >>>> either is with "vector unsigned char" as argument type, but > the corresponding instance > >>>> prototype in builtin table is with "vector signed char". > It's inconsistent and weird, > >>>> I think we can just update the prototype in builtin table > with "vector unsigned char" > >>>> and remove the entries in overload table. It can be a follow > up patch. > >>> > >>> I didn't notice that it was signed in the instance prototype > but unsigned in the overloaded definition. That is definitely > inconsistent. > >>> > >>> That said, should we just go ahead and support both signed and > unsigned argument versions of the all ones and all zeros built-ins? > >> > >> Good question, I thought about that but found openxl only > supports the unsigned version > >> so I felt it's probably better to keep consistent with it. But > I'm fine for either, if > >> we decide to extend it to cover both signed and unsigned, we > should notify openxl team > >> to extend it as well. > >> > >> openxl doc links: > >> > >> > https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-ones > >> > https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-zeros > > > > If it makes sense to support vector signed char rather than only > the vector unsigned char, > > then I'm fine adding support for it. It almost seems since we > tried adding an overload > > for it, that that was our intention (to support both signed and > unsigned) and we just > > had a bug so only unsigned was supported? > > Good question but I'm not sure, it could be an oversight without > adding one more instance > for overloading, or adopting some useless code (only for > overloading) for a single instance. > I found it's introduced by r11-2437-gcf5d0fc2d1adcd, CC'ed Will as > he contributed this. > > BR, > Kewen > > > > > CC'ing Steve since he noticed the missing documentation when we > was trying to > > use the built-ins. Steve, do you see a need to also support > vector signed char > > with these built-ins? > > > > Peter > > > > >
Steve, Peter, Kewen: Yes, it does look like supporting signed and unsigned char would be consistent with the vec_cmpeq built-in.n I have played around with adding both and it looks to be reasonable. Per your second response: On 8/7/24 9:25 AM, Steven Munroe wrote: > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-XFVHHo6HWfV3b_T4u-ovzvM2oECEmlsAI8bs75KG8ppbxA0ZMm3tLYvA1X6MiILD9q66A8Zvx82vUGfKlRvNQL57yam4nxYX3qt72hHJCHgHCIrFLK48OJa7w$> > > Actually for consistency should include vector bool/signed/unsigned char. I haven't looked at including vector bool but at first glance don't see any reason why that couldn't be supported as well. I will look at adding the additional vector signed char and and vector bool instances to both of the built-ins as well as adding documentation for all of the supported instances. Carl On 8/7/24 9:24 AM, Steven Munroe wrote: > I would compare this case to vec_cmpeq. It supports both vector > unsigned/signed char operands but generates the same instruction for > either. So it would seem more consistent with the history of > altivec. h to support both unsigned/sign char for > > I would compare this case to vec_cmpeq. > > It supports both vector unsigned/signed char operands but generates > the same instruction for either. > > So it would seem more consistent with the history of altivec.h to > support both unsigned/sign char for > > > vec_test_lsbb_all_ones, vec_test_lsbb_all_zeros > > And this might make life a little easier for users. > > > On Tue, Aug 6, 2024 at 10:12 AM Carl Love <cel@linux.ibm.com> wrote: > > Steve: > > Agreed the documentation only specifies unsigned char argument for > the > two built-ins. > > Do you think we should add support signed char arguments in > addition to > the documented unsigned char arguments? > > Do you see any situations where a user might want to to have both > signed > and unsigned char arguments for the two built-ins? > > Thanks. > > Carl > > On 8/5/24 2:12 PM, Steven Munroe wrote: > > Looking at the latest version of the Power Vector Intrinsic > > Programming Reference (Revision 2. 0. 0_prd, Bill slipped this > to me > > for review), I see that vec_test_lsbb_all_ones > vec_test_lsbb_all_zeros > > both specify vector unsigned char, only. On > > > > Looking at the latest version of the Power Vector Intrinsic > > Programming Reference (Revision 2.0.0_prd, Bill slipped this to > me for > > review), I see that > > > > > > vec_test_lsbb_all_ones > > > > > > vec_test_lsbb_all_zeros > > > > both specify vector unsigned char, only. > > > > On Mon, Aug 5, 2024 at 1:15 AM Kewen.Lin <linkw@linux.ibm.com> > wrote: > > > > on 2024/8/3 05:48, Peter Bergner wrote: > > > On 7/31/24 10:21 PM, Kewen.Lin wrote: > > >> on 2024/8/1 01:52, Carl Love wrote: > > >>> Yes, I noticed that the built-ins were defined as overloaded > > but only had one definition. Did seem odd to me. > > >>> > > >>>> either is with "vector unsigned char" as argument type, but > > the corresponding instance > > >>>> prototype in builtin table is with "vector signed char". > > It's inconsistent and weird, > > >>>> I think we can just update the prototype in builtin table > > with "vector unsigned char" > > >>>> and remove the entries in overload table. It can be a > follow > > up patch. > > >>> > > >>> I didn't notice that it was signed in the instance prototype > > but unsigned in the overloaded definition. That is definitely > > inconsistent. > > >>> > > >>> That said, should we just go ahead and support both > signed and > > unsigned argument versions of the all ones and all zeros > built-ins? > > >> > > >> Good question, I thought about that but found openxl only > > supports the unsigned version > > >> so I felt it's probably better to keep consistent with > it. But > > I'm fine for either, if > > >> we decide to extend it to cover both signed and unsigned, we > > should notify openxl team > > >> to extend it as well. > > >> > > >> openxl doc links: > > >> > > >> > > > https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-ones > > >> > > > https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.2?topic=functions-vec-test-lsbb-all-zeros > > > > > > If it makes sense to support vector signed char rather > than only > > the vector unsigned char, > > > then I'm fine adding support for it. It almost seems since we > > tried adding an overload > > > for it, that that was our intention (to support both > signed and > > unsigned) and we just > > > had a bug so only unsigned was supported? > > > > Good question but I'm not sure, it could be an oversight without > > adding one more instance > > for overloading, or adopting some useless code (only for > > overloading) for a single instance. > > I found it's introduced by r11-2437-gcf5d0fc2d1adcd, CC'ed > Will as > > he contributed this. > > > > BR, > > Kewen > > > > > > > > CC'ing Steve since he noticed the missing documentation > when we > > was trying to > > > use the built-ins. Steve, do you see a need to also support > > vector signed char > > > with these built-ins? > > > > > > Peter > > > > > > > > >
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 83ff168faf6..96e41c9a905 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -23240,6 +23240,21 @@ signed long long will sign extend the rightmost byte of each doubleword. The following additional built-in functions are also available for the PowerPC family of processors, starting with ISA 3.1 (@option{-mcpu=power10}): +@smallexample +@exdent int vec_test_lsbb_all_ones (vector char); +@end smallexample +@findex vec_test_lsbb_all_ones + +The builtin @code{vec_test_lsbb_all_ones} returns 1 if the least significant +bit in each byte is a one. It returns a zero otherwise. + +@smallexample +@exdent int vec_test_lsbb_all_zeros (vector char); +@end smallexample +@findex vec_test_lsbb_all_zeros + +The builtin @code{vec_test_lsbb_all_zeros} returns 1 if the least significant