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 <c...@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 <li...@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
> >
> >
>
