Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Hi Jeff,
on 2023/4/13 15:45, guojiufu wrote:
> Hi,
>
> On 2023-04-12 20:47, Kewen.Lin wrote:
>> Hi Segher & Jeff,
>>
>> on 2023/4/11 23:13, Segher Boessenkool wrote:
>>> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
on 2023/4/11 17:14, guojiufu wrote:
> Thanks for raising this concern.
> The behavior to check about bif on FLOAT128_HW and emit an error message
> for
> requirements on quad-precision is added in gcc12. This is why gcc12 fails
> to
> compile the case on -m32.
>
> Before gcc12, altivec_resolve_overloaded_builtin will return the
> overloaded
> result directly, and does not check more about the result function.
Thanks for checking, I wonder which commit caused this behavior change and
what's
the underlying justification? I know there is one new bif handling
framework
>>
>> Answered this question by myself with some diggings, test case
>> float128-cmp2-runnable.c started to fail from r12-5752-gd08236359eb229 which
>> exactly makes new bif framework start to take effect and the reason why the
>> behavior changes is the condition change from **TARGET_P9_VECTOR** to
>> **TARGET_FLOAT128_HW**.
>>
>> With r12-5751-gc9dd01314d8467 (still old bif framework):
>>
>> $ grep -r scalar_cmp_exp_qp gcc/config/rs6000/rs6000-builtin.def
>> BU_P9V_VSX_2 (VSCEQPGT, "scalar_cmp_exp_qp_gt", CONST, xscmpexpqp_gt_kf)
>> BU_P9V_VSX_2 (VSCEQPLT, "scalar_cmp_exp_qp_lt", CONST, xscmpexpqp_lt_kf)
>> BU_P9V_VSX_2 (VSCEQPEQ, "scalar_cmp_exp_qp_eq", CONST, xscmpexpqp_eq_kf)
>> BU_P9V_VSX_2 (VSCEQPUO, "scalar_cmp_exp_qp_unordered", CONST,
>> xscmpexpqp_unordered_kf)
>> BU_P9V_OVERLOAD_2 (VSCEQPGT, "scalar_cmp_exp_qp_gt")
>> BU_P9V_OVERLOAD_2 (VSCEQPLT, "scalar_cmp_exp_qp_lt")
>> BU_P9V_OVERLOAD_2 (VSCEQPEQ, "scalar_cmp_exp_qp_eq")
>> BU_P9V_OVERLOAD_2 (VSCEQPUO, "scalar_cmp_exp_qp_unordered")
>>
>> There were only 13 bifs requiring TARGET_FLOAT128_HW in old bif framework.
>>
>> $ grep ^BU_FLOAT128_HW gcc/config/rs6000/rs6000-builtin.def
>> BU_FLOAT128_HW_VSX_1 (VSEEQP, "scalar_extract_expq", CONST, xsxexpqp_kf)
>> BU_FLOAT128_HW_VSX_1 (VSESQP, "scalar_extract_sigq", CONST, xsxsigqp_kf)
>> BU_FLOAT128_HW_VSX_1 (VSTDCNQP, "scalar_test_neg_qp", CONST,
>> xststdcnegqp_kf)
>> BU_FLOAT128_HW_VSX_2 (VSIEQP, "scalar_insert_exp_q", CONST, xsiexpqp_kf)
>> BU_FLOAT128_HW_VSX_2 (VSIEQPF, "scalar_insert_exp_qp", CONST, xsiexpqpf_kf)
>> BU_FLOAT128_HW_VSX_2 (VSTDCQP, "scalar_test_data_class_qp", CONST,
>> xststdcqp_kf)
>> BU_FLOAT128_HW_1 (SQRTF128_ODD, "sqrtf128_round_to_odd", FP, sqrtkf2_odd)
>> BU_FLOAT128_HW_1 (TRUNCF128_ODD, "truncf128_round_to_odd", FP,
>> trunckfdf2_odd)
>> BU_FLOAT128_HW_2 (ADDF128_ODD, "addf128_round_to_odd", FP, addkf3_odd)
>> BU_FLOAT128_HW_2 (SUBF128_ODD, "subf128_round_to_odd", FP, subkf3_odd)
>> BU_FLOAT128_HW_2 (MULF128_ODD, "mulf128_round_to_odd", FP, mulkf3_odd)
>> BU_FLOAT128_HW_2 (DIVF128_ODD, "divf128_round_to_odd", FP, divkf3_odd)
>> BU_FLOAT128_HW_3 (FMAF128_ODD, "fmaf128_round_to_odd", FP, fmakf4_odd)
>>
>> Starting from r12-5752-gd08236359eb229, these
>> scalar_cmp_exp_qp_{gt,lt,eq,unordered}
>> bifs were put under stanza ieee128-hw, it makes ieee128-hw to have 17 bifs,
>> comparing to the previous, the extra four ones were exactly these
>> scalar_cmp_exp_qp_{gt,lt,eq,unordered}.
>>
introduced in gcc12, not sure the checking condition was changed together
or by
a standalone commit. Anyway, apparently the conditions for the support of
these
bifs are different on gcc-11 and gcc-12, I wonder why it changed. As
mentioned
above, PR108758's c#1 said this case (bifs) work well on gcc-11, I
suspected the
condition change was an overkill, that's why I asked.
>>>
>>> It almost certainly was an oversight. The new builtin framework changed
>>> so many things, there was bound to be some breakage to go with all the
>>> good things it brought.
>>
>> Yeah, as the above findings, also I found that
>> r12-3126-g2ed356a4c9af06 introduced
>> power9 related stanzas and r12-3167-g2f9489a1009d98 introduced ieee128-hw
>> stanza
>> including these four bifs, both of them don't have any notes on why we
>> would change
>> the condition for these scalar_cmp_exp_qp_{gt,lt,eq,unordered} from
>> power9-vector to
>> ieee128-hw, so I think it's just an oversight (ieee128-hw is an
>> overkill comparing
>> to power9-vector :)).
>>
>>>
>>> So what is the actual thing going wrong? QP insns work fine and are
>>> valid on all systems and environments, BE or LE, 32-bit or 64-bit. Of
>>> course you cannot use the "long double" type for those everywhere, but
>>> that is a very different thing.
>>
>> The actual thing going wrong is that: the test case float128-cmp2-runnable.c
>> runs well on BE -m32 and -m64 with gcc-11, but meets failures on BE -m32 with
>> latest gcc-12 and trunk during compilation, having the error messages like:
>>
>>
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Hi,
On 2023-04-12 20:47, Kewen.Lin wrote:
Hi Segher & Jeff,
on 2023/4/11 23:13, Segher Boessenkool wrote:
On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
on 2023/4/11 17:14, guojiufu wrote:
Thanks for raising this concern.
The behavior to check about bif on FLOAT128_HW and emit an error
message for
requirements on quad-precision is added in gcc12. This is why gcc12
fails to
compile the case on -m32.
Before gcc12, altivec_resolve_overloaded_builtin will return the
overloaded
result directly, and does not check more about the result function.
Thanks for checking, I wonder which commit caused this behavior
change and what's
the underlying justification? I know there is one new bif handling
framework
Answered this question by myself with some diggings, test case
float128-cmp2-runnable.c started to fail from r12-5752-gd08236359eb229
which
exactly makes new bif framework start to take effect and the reason why
the
behavior changes is the condition change from **TARGET_P9_VECTOR** to
**TARGET_FLOAT128_HW**.
With r12-5751-gc9dd01314d8467 (still old bif framework):
$ grep -r scalar_cmp_exp_qp gcc/config/rs6000/rs6000-builtin.def
BU_P9V_VSX_2 (VSCEQPGT, "scalar_cmp_exp_qp_gt", CONST,
xscmpexpqp_gt_kf)
BU_P9V_VSX_2 (VSCEQPLT, "scalar_cmp_exp_qp_lt", CONST,
xscmpexpqp_lt_kf)
BU_P9V_VSX_2 (VSCEQPEQ, "scalar_cmp_exp_qp_eq", CONST,
xscmpexpqp_eq_kf)
BU_P9V_VSX_2 (VSCEQPUO, "scalar_cmp_exp_qp_unordered", CONST,
xscmpexpqp_unordered_kf)
BU_P9V_OVERLOAD_2 (VSCEQPGT,"scalar_cmp_exp_qp_gt")
BU_P9V_OVERLOAD_2 (VSCEQPLT,"scalar_cmp_exp_qp_lt")
BU_P9V_OVERLOAD_2 (VSCEQPEQ,"scalar_cmp_exp_qp_eq")
BU_P9V_OVERLOAD_2 (VSCEQPUO,"scalar_cmp_exp_qp_unordered")
There were only 13 bifs requiring TARGET_FLOAT128_HW in old bif
framework.
$ grep ^BU_FLOAT128_HW gcc/config/rs6000/rs6000-builtin.def
BU_FLOAT128_HW_VSX_1 (VSEEQP, "scalar_extract_expq", CONST,
xsxexpqp_kf)
BU_FLOAT128_HW_VSX_1 (VSESQP, "scalar_extract_sigq", CONST,
xsxsigqp_kf)
BU_FLOAT128_HW_VSX_1 (VSTDCNQP, "scalar_test_neg_qp", CONST,
xststdcnegqp_kf)
BU_FLOAT128_HW_VSX_2 (VSIEQP, "scalar_insert_exp_q", CONST,
xsiexpqp_kf)
BU_FLOAT128_HW_VSX_2 (VSIEQPF, "scalar_insert_exp_qp", CONST,
xsiexpqpf_kf)
BU_FLOAT128_HW_VSX_2 (VSTDCQP, "scalar_test_data_class_qp", CONST,
xststdcqp_kf)
BU_FLOAT128_HW_1 (SQRTF128_ODD, "sqrtf128_round_to_odd", FP,
sqrtkf2_odd)
BU_FLOAT128_HW_1 (TRUNCF128_ODD, "truncf128_round_to_odd", FP,
trunckfdf2_odd)
BU_FLOAT128_HW_2 (ADDF128_ODD, "addf128_round_to_odd", FP,
addkf3_odd)
BU_FLOAT128_HW_2 (SUBF128_ODD, "subf128_round_to_odd", FP,
subkf3_odd)
BU_FLOAT128_HW_2 (MULF128_ODD, "mulf128_round_to_odd", FP,
mulkf3_odd)
BU_FLOAT128_HW_2 (DIVF128_ODD, "divf128_round_to_odd", FP,
divkf3_odd)
BU_FLOAT128_HW_3 (FMAF128_ODD, "fmaf128_round_to_odd", FP,
fmakf4_odd)
Starting from r12-5752-gd08236359eb229, these
scalar_cmp_exp_qp_{gt,lt,eq,unordered}
bifs were put under stanza ieee128-hw, it makes ieee128-hw to have 17
bifs,
comparing to the previous, the extra four ones were exactly these
scalar_cmp_exp_qp_{gt,lt,eq,unordered}.
introduced in gcc12, not sure the checking condition was changed
together or by
a standalone commit. Anyway, apparently the conditions for the
support of these
bifs are different on gcc-11 and gcc-12, I wonder why it changed. As
mentioned
above, PR108758's c#1 said this case (bifs) work well on gcc-11, I
suspected the
condition change was an overkill, that's why I asked.
It almost certainly was an oversight. The new builtin framework
changed
so many things, there was bound to be some breakage to go with all the
good things it brought.
Yeah, as the above findings, also I found that
r12-3126-g2ed356a4c9af06 introduced
power9 related stanzas and r12-3167-g2f9489a1009d98 introduced
ieee128-hw stanza
including these four bifs, both of them don't have any notes on why we
would change
the condition for these scalar_cmp_exp_qp_{gt,lt,eq,unordered} from
power9-vector to
ieee128-hw, so I think it's just an oversight (ieee128-hw is an
overkill comparing
to power9-vector :)).
So what is the actual thing going wrong? QP insns work fine and are
valid on all systems and environments, BE or LE, 32-bit or 64-bit. Of
course you cannot use the "long double" type for those everywhere, but
that is a very different thing.
The actual thing going wrong is that: the test case
float128-cmp2-runnable.c
runs well on BE -m32 and -m64 with gcc-11, but meets failures on BE
-m32 with
latest gcc-12 and trunk during compilation, having the error messages
like:
gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c: In function
'main':
gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:155:3: error:
'__builtin_vsx_scalar_cmp_exp_qp_eq' requires ISA 3.0 IEEE 128-bit
floating point
As scalar_cmp_exp_qp_{gt,lt,eq,unordered} requires condition
TARGET_FLOAT128_HW
now (since new bif framework took effect).
(To be
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
on 2023/4/12 20:47, Kewen.Lin wrote:
> Hi Segher & Jeff,
>
> on 2023/4/11 23:13, Segher Boessenkool wrote:
>> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
>>> on 2023/4/11 17:14, guojiufu wrote:
Thanks for raising this concern.
The behavior to check about bif on FLOAT128_HW and emit an error message
for
requirements on quad-precision is added in gcc12. This is why gcc12 fails
to
compile the case on -m32.
Before gcc12, altivec_resolve_overloaded_builtin will return the overloaded
result directly, and does not check more about the result function.
>>>
>>> Thanks for checking, I wonder which commit caused this behavior change and
>>> what's
>>> the underlying justification? I know there is one new bif handling
>>> framework
>
> Answered this question by myself with some diggings, test case
> float128-cmp2-runnable.c started to fail from r12-5752-gd08236359eb229 which
> exactly makes new bif framework start to take effect and the reason why the
> behavior changes is the condition change from **TARGET_P9_VECTOR** to
> **TARGET_FLOAT128_HW**.
>
> With r12-5751-gc9dd01314d8467 (still old bif framework):
>
> $ grep -r scalar_cmp_exp_qp gcc/config/rs6000/rs6000-builtin.def
> BU_P9V_VSX_2 (VSCEQPGT, "scalar_cmp_exp_qp_gt", CONST, xscmpexpqp_gt_kf)
> BU_P9V_VSX_2 (VSCEQPLT, "scalar_cmp_exp_qp_lt", CONST, xscmpexpqp_lt_kf)
> BU_P9V_VSX_2 (VSCEQPEQ, "scalar_cmp_exp_qp_eq", CONST, xscmpexpqp_eq_kf)
> BU_P9V_VSX_2 (VSCEQPUO, "scalar_cmp_exp_qp_unordered", CONST,
> xscmpexpqp_unordered_kf)
> BU_P9V_OVERLOAD_2 (VSCEQPGT,"scalar_cmp_exp_qp_gt")
> BU_P9V_OVERLOAD_2 (VSCEQPLT,"scalar_cmp_exp_qp_lt")
> BU_P9V_OVERLOAD_2 (VSCEQPEQ,"scalar_cmp_exp_qp_eq")
> BU_P9V_OVERLOAD_2 (VSCEQPUO,"scalar_cmp_exp_qp_unordered")
>
> There were only 13 bifs requiring TARGET_FLOAT128_HW in old bif framework.
>
> $ grep ^BU_FLOAT128_HW gcc/config/rs6000/rs6000-builtin.def
> BU_FLOAT128_HW_VSX_1 (VSEEQP, "scalar_extract_expq", CONST, xsxexpqp_kf)
> BU_FLOAT128_HW_VSX_1 (VSESQP, "scalar_extract_sigq", CONST, xsxsigqp_kf)
> BU_FLOAT128_HW_VSX_1 (VSTDCNQP, "scalar_test_neg_qp", CONST,
> xststdcnegqp_kf)
> BU_FLOAT128_HW_VSX_2 (VSIEQP, "scalar_insert_exp_q", CONST, xsiexpqp_kf)
> BU_FLOAT128_HW_VSX_2 (VSIEQPF, "scalar_insert_exp_qp", CONST, xsiexpqpf_kf)
> BU_FLOAT128_HW_VSX_2 (VSTDCQP, "scalar_test_data_class_qp", CONST,
> xststdcqp_kf)
> BU_FLOAT128_HW_1 (SQRTF128_ODD, "sqrtf128_round_to_odd", FP, sqrtkf2_odd)
> BU_FLOAT128_HW_1 (TRUNCF128_ODD, "truncf128_round_to_odd", FP, trunckfdf2_odd)
> BU_FLOAT128_HW_2 (ADDF128_ODD, "addf128_round_to_odd", FP, addkf3_odd)
> BU_FLOAT128_HW_2 (SUBF128_ODD, "subf128_round_to_odd", FP, subkf3_odd)
> BU_FLOAT128_HW_2 (MULF128_ODD, "mulf128_round_to_odd", FP, mulkf3_odd)
> BU_FLOAT128_HW_2 (DIVF128_ODD, "divf128_round_to_odd", FP, divkf3_odd)
> BU_FLOAT128_HW_3 (FMAF128_ODD, "fmaf128_round_to_odd", FP, fmakf4_odd)
>
> Starting from r12-5752-gd08236359eb229, these
> scalar_cmp_exp_qp_{gt,lt,eq,unordered}
> bifs were put under stanza ieee128-hw, it makes ieee128-hw to have 17 bifs,
> comparing to the previous, the extra four ones were exactly these
> scalar_cmp_exp_qp_{gt,lt,eq,unordered}.
>
>>> introduced in gcc12, not sure the checking condition was changed together
>>> or by
>>> a standalone commit. Anyway, apparently the conditions for the support of
>>> these
>>> bifs are different on gcc-11 and gcc-12, I wonder why it changed. As
>>> mentioned
>>> above, PR108758's c#1 said this case (bifs) work well on gcc-11, I
>>> suspected the
>>> condition change was an overkill, that's why I asked.
>>
>> It almost certainly was an oversight. The new builtin framework changed
>> so many things, there was bound to be some breakage to go with all the
>> good things it brought.
>
> Yeah, as the above findings, also I found that r12-3126-g2ed356a4c9af06
> introduced
> power9 related stanzas and r12-3167-g2f9489a1009d98 introduced ieee128-hw
> stanza
> including these four bifs, both of them don't have any notes on why we would
> change
> the condition for these scalar_cmp_exp_qp_{gt,lt,eq,unordered} from
> power9-vector to
> ieee128-hw, so I think it's just an oversight (ieee128-hw is an overkill
> comparing
> to power9-vector :)).
>
>>
>> So what is the actual thing going wrong? QP insns work fine and are
>> valid on all systems and environments, BE or LE, 32-bit or 64-bit. Of
>> course you cannot use the "long double" type for those everywhere, but
>> that is a very different thing.
>
> The actual thing going wrong is that: the test case float128-cmp2-runnable.c
> runs well on BE -m32 and -m64 with gcc-11, but meets failures on BE -m32 with
> latest gcc-12 and trunk during compilation, having the error messages like:
>
> gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c: In function 'main':
> gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:155:3:
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Hi Mike, On 2023-04-12 22:46, Michael Meissner wrote: On Wed, Apr 12, 2023 at 01:31:46PM +0800, Jiufu Guo wrote: I understand that QP insns (e.g. xscmpexpqp) is valid if the system meets ISA3.0, no matter BE/LE, 32-bit/64-bit. I think option -mfloat128-hardware is designed for QP insns. While there is one issue, on BE machine, when compiling with options "-mfloat128-hardware -m32", an error message is generated: "error: '%<-mfloat128-hardware%>' requires '-m64'" (I'm wondering if we need to relax this limitation.) In the past, the machine independent portion of the compiler demanded that for scalar mode, there be an integer mode of the same size, since sometimes moves are converted to using an int RTL mode. Since we don't have TImode support in 32-bit, you would get various errors because something tried to do a TImode move for KFmode types, and the TImode wasn't available. If somebody wants to verify that this now works on 32-bit and/or implements TImode on 32-bit, then we can relax the restriction. Thanks a lot for pointing out this! BR, Jeff (Jiufu)
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
On Wed, Apr 12, 2023 at 01:31:46PM +0800, Jiufu Guo wrote: > I understand that QP insns (e.g. xscmpexpqp) is valid if the system > meets ISA3.0, no matter BE/LE, 32-bit/64-bit. > I think option -mfloat128-hardware is designed for QP insns. > > While there is one issue, on BE machine, when compiling with options > "-mfloat128-hardware -m32", an error message is generated: > "error: '%<-mfloat128-hardware%>' requires '-m64'" > > (I'm wondering if we need to relax this limitation.) In the past, the machine independent portion of the compiler demanded that for scalar mode, there be an integer mode of the same size, since sometimes moves are converted to using an int RTL mode. Since we don't have TImode support in 32-bit, you would get various errors because something tried to do a TImode move for KFmode types, and the TImode wasn't available. If somebody wants to verify that this now works on 32-bit and/or implements TImode on 32-bit, then we can relax the restriction. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Hi Segher & Jeff,
on 2023/4/11 23:13, Segher Boessenkool wrote:
> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote:
>> on 2023/4/11 17:14, guojiufu wrote:
>>> Thanks for raising this concern.
>>> The behavior to check about bif on FLOAT128_HW and emit an error message for
>>> requirements on quad-precision is added in gcc12. This is why gcc12 fails to
>>> compile the case on -m32.
>>>
>>> Before gcc12, altivec_resolve_overloaded_builtin will return the overloaded
>>> result directly, and does not check more about the result function.
>>
>> Thanks for checking, I wonder which commit caused this behavior change and
>> what's
>> the underlying justification? I know there is one new bif handling framework
Answered this question by myself with some diggings, test case
float128-cmp2-runnable.c started to fail from r12-5752-gd08236359eb229 which
exactly makes new bif framework start to take effect and the reason why the
behavior changes is the condition change from **TARGET_P9_VECTOR** to
**TARGET_FLOAT128_HW**.
With r12-5751-gc9dd01314d8467 (still old bif framework):
$ grep -r scalar_cmp_exp_qp gcc/config/rs6000/rs6000-builtin.def
BU_P9V_VSX_2 (VSCEQPGT, "scalar_cmp_exp_qp_gt", CONST, xscmpexpqp_gt_kf)
BU_P9V_VSX_2 (VSCEQPLT, "scalar_cmp_exp_qp_lt", CONST, xscmpexpqp_lt_kf)
BU_P9V_VSX_2 (VSCEQPEQ, "scalar_cmp_exp_qp_eq", CONST, xscmpexpqp_eq_kf)
BU_P9V_VSX_2 (VSCEQPUO, "scalar_cmp_exp_qp_unordered", CONST,
xscmpexpqp_unordered_kf)
BU_P9V_OVERLOAD_2 (VSCEQPGT,"scalar_cmp_exp_qp_gt")
BU_P9V_OVERLOAD_2 (VSCEQPLT,"scalar_cmp_exp_qp_lt")
BU_P9V_OVERLOAD_2 (VSCEQPEQ,"scalar_cmp_exp_qp_eq")
BU_P9V_OVERLOAD_2 (VSCEQPUO,"scalar_cmp_exp_qp_unordered")
There were only 13 bifs requiring TARGET_FLOAT128_HW in old bif framework.
$ grep ^BU_FLOAT128_HW gcc/config/rs6000/rs6000-builtin.def
BU_FLOAT128_HW_VSX_1 (VSEEQP, "scalar_extract_expq", CONST, xsxexpqp_kf)
BU_FLOAT128_HW_VSX_1 (VSESQP, "scalar_extract_sigq", CONST, xsxsigqp_kf)
BU_FLOAT128_HW_VSX_1 (VSTDCNQP, "scalar_test_neg_qp", CONST, xststdcnegqp_kf)
BU_FLOAT128_HW_VSX_2 (VSIEQP, "scalar_insert_exp_q", CONST, xsiexpqp_kf)
BU_FLOAT128_HW_VSX_2 (VSIEQPF, "scalar_insert_exp_qp", CONST, xsiexpqpf_kf)
BU_FLOAT128_HW_VSX_2 (VSTDCQP, "scalar_test_data_class_qp", CONST,
xststdcqp_kf)
BU_FLOAT128_HW_1 (SQRTF128_ODD, "sqrtf128_round_to_odd", FP, sqrtkf2_odd)
BU_FLOAT128_HW_1 (TRUNCF128_ODD, "truncf128_round_to_odd", FP, trunckfdf2_odd)
BU_FLOAT128_HW_2 (ADDF128_ODD, "addf128_round_to_odd", FP, addkf3_odd)
BU_FLOAT128_HW_2 (SUBF128_ODD, "subf128_round_to_odd", FP, subkf3_odd)
BU_FLOAT128_HW_2 (MULF128_ODD, "mulf128_round_to_odd", FP, mulkf3_odd)
BU_FLOAT128_HW_2 (DIVF128_ODD, "divf128_round_to_odd", FP, divkf3_odd)
BU_FLOAT128_HW_3 (FMAF128_ODD, "fmaf128_round_to_odd", FP, fmakf4_odd)
Starting from r12-5752-gd08236359eb229, these
scalar_cmp_exp_qp_{gt,lt,eq,unordered}
bifs were put under stanza ieee128-hw, it makes ieee128-hw to have 17 bifs,
comparing to the previous, the extra four ones were exactly these
scalar_cmp_exp_qp_{gt,lt,eq,unordered}.
>> introduced in gcc12, not sure the checking condition was changed together or
>> by
>> a standalone commit. Anyway, apparently the conditions for the support of
>> these
>> bifs are different on gcc-11 and gcc-12, I wonder why it changed. As
>> mentioned
>> above, PR108758's c#1 said this case (bifs) work well on gcc-11, I suspected
>> the
>> condition change was an overkill, that's why I asked.
>
> It almost certainly was an oversight. The new builtin framework changed
> so many things, there was bound to be some breakage to go with all the
> good things it brought.
Yeah, as the above findings, also I found that r12-3126-g2ed356a4c9af06
introduced
power9 related stanzas and r12-3167-g2f9489a1009d98 introduced ieee128-hw stanza
including these four bifs, both of them don't have any notes on why we would
change
the condition for these scalar_cmp_exp_qp_{gt,lt,eq,unordered} from
power9-vector to
ieee128-hw, so I think it's just an oversight (ieee128-hw is an overkill
comparing
to power9-vector :)).
>
> So what is the actual thing going wrong? QP insns work fine and are
> valid on all systems and environments, BE or LE, 32-bit or 64-bit. Of
> course you cannot use the "long double" type for those everywhere, but
> that is a very different thing.
The actual thing going wrong is that: the test case float128-cmp2-runnable.c
runs well on BE -m32 and -m64 with gcc-11, but meets failures on BE -m32 with
latest gcc-12 and trunk during compilation, having the error messages like:
gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c: In function 'main':
gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c:155:3: error:
'__builtin_vsx_scalar_cmp_exp_qp_eq' requires ISA 3.0 IEEE 128-bit floating
point
As scalar_cmp_exp_qp_{gt,lt,eq,unordered} requires condition TARGET_FLOAT128_HW
now (since new bif framework took effect).
(To be
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Jiufu Guo via Gcc-patches writes: > Hi, > > Segher Boessenkool writes: > >> On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote: >>> on 2023/4/11 17:14, guojiufu wrote: >>> > Thanks for raising this concern. >>> > The behavior to check about bif on FLOAT128_HW and emit an error message >>> > for >>> > requirements on quad-precision is added in gcc12. This is why gcc12 fails >>> > to >>> > compile the case on -m32. >>> > >>> > Before gcc12, altivec_resolve_overloaded_builtin will return the >>> > overloaded >>> > result directly, and does not check more about the result function. >>> >>> Thanks for checking, I wonder which commit caused this behavior change and >>> what's >>> the underlying justification? I know there is one new bif handling >>> framework >>> introduced in gcc12, not sure the checking condition was changed together >>> or by >>> a standalone commit. Anyway, apparently the conditions for the support of >>> these >>> bifs are different on gcc-11 and gcc-12, I wonder why it changed. As >>> mentioned >>> above, PR108758's c#1 said this case (bifs) work well on gcc-11, I >>> suspected the >>> condition change was an overkill, that's why I asked. >> >> It almost certainly was an oversight. The new builtin framework changed >> so many things, there was bound to be some breakage to go with all the >> good things it brought. > > Yes, the condition checking on gcc-12 is different from gcc-11. In > gcc-11, the condition on overloaded bif is not checked. > And, there are a few commits related to the bifs change. e.g. > r12-4977-ga28cfe49203705 introduces a new bif expand function which has > the ability to check more bif's target requirements like ieee128_hw. > And another commit changes the error message (r12-6684). > >> >> So what is the actual thing going wrong? QP insns work fine and are >> valid on all systems and environments, BE or LE, 32-bit or 64-bit. >> Of I understand that QP insns (e.g. xscmpexpqp) is valid if the system meets ISA3.0, no matter BE/LE, 32-bit/64-bit. I think option -mfloat128-hardware is designed for QP insns. While there is one issue, on BE machine, when compiling with options "-mfloat128-hardware -m32", an error message is generated: "error: '%<-mfloat128-hardware%>' requires '-m64'" (I'm wondering if we need to relax this limitation.) BR, Jeff (Jiufu) >> course you cannot use the "long double" type for those everywhere, but >> that is a very different thing. > > Currently, when compiling bif __builtin_vsx_scalar_cmp_exp_qp_eq, > gcc generates error message: > error: '__builtin_vsx_scalar_cmp_exp_qp_eq' requires quad-precision > floating-point arithmetic > > IMHO, this error would be ok. Because it makes sense that this bif > needs ieee128_hw. > > BR, > Jeff (Jiufu) > >> >> >> Segher
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Hi, Segher Boessenkool writes: > On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote: >> on 2023/4/11 17:14, guojiufu wrote: >> > Thanks for raising this concern. >> > The behavior to check about bif on FLOAT128_HW and emit an error message >> > for >> > requirements on quad-precision is added in gcc12. This is why gcc12 fails >> > to >> > compile the case on -m32. >> > >> > Before gcc12, altivec_resolve_overloaded_builtin will return the overloaded >> > result directly, and does not check more about the result function. >> >> Thanks for checking, I wonder which commit caused this behavior change and >> what's >> the underlying justification? I know there is one new bif handling framework >> introduced in gcc12, not sure the checking condition was changed together or >> by >> a standalone commit. Anyway, apparently the conditions for the support of >> these >> bifs are different on gcc-11 and gcc-12, I wonder why it changed. As >> mentioned >> above, PR108758's c#1 said this case (bifs) work well on gcc-11, I suspected >> the >> condition change was an overkill, that's why I asked. > > It almost certainly was an oversight. The new builtin framework changed > so many things, there was bound to be some breakage to go with all the > good things it brought. Yes, the condition checking on gcc-12 is different from gcc-11. In gcc-11, the condition on overloaded bif is not checked. And, there are a few commits related to the bifs change. e.g. r12-4977-ga28cfe49203705 introduces a new bif expand function which has the ability to check more bif's target requirements like ieee128_hw. And another commit changes the error message (r12-6684). > > So what is the actual thing going wrong? QP insns work fine and are > valid on all systems and environments, BE or LE, 32-bit or 64-bit. Of > course you cannot use the "long double" type for those everywhere, but > that is a very different thing. Currently, when compiling bif __builtin_vsx_scalar_cmp_exp_qp_eq, gcc generates error message: error: '__builtin_vsx_scalar_cmp_exp_qp_eq' requires quad-precision floating-point arithmetic IMHO, this error would be ok. Because it makes sense that this bif needs ieee128_hw. BR, Jeff (Jiufu) > > > Segher
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
On Tue, Apr 11, 2023 at 05:40:09PM +0800, Kewen.Lin wrote: > on 2023/4/11 17:14, guojiufu wrote: > > Thanks for raising this concern. > > The behavior to check about bif on FLOAT128_HW and emit an error message for > > requirements on quad-precision is added in gcc12. This is why gcc12 fails to > > compile the case on -m32. > > > > Before gcc12, altivec_resolve_overloaded_builtin will return the overloaded > > result directly, and does not check more about the result function. > > Thanks for checking, I wonder which commit caused this behavior change and > what's > the underlying justification? I know there is one new bif handling framework > introduced in gcc12, not sure the checking condition was changed together or > by > a standalone commit. Anyway, apparently the conditions for the support of > these > bifs are different on gcc-11 and gcc-12, I wonder why it changed. As > mentioned > above, PR108758's c#1 said this case (bifs) work well on gcc-11, I suspected > the > condition change was an overkill, that's why I asked. It almost certainly was an oversight. The new builtin framework changed so many things, there was bound to be some breakage to go with all the good things it brought. So what is the actual thing going wrong? QP insns work fine and are valid on all systems and environments, BE or LE, 32-bit or 64-bit. Of course you cannot use the "long double" type for those everywhere, but that is a very different thing. Segher
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Hi Jeff,
on 2023/4/11 17:14, guojiufu wrote:
> Hi Kewen,
>
> Thanks a lot for your very helpful comments!
>
> On 2023-04-10 17:26, Kewen.Lin wrote:
>> Hi Jeff,
>>
>> on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
>>> Hi,
>>>
>>> In this test case (float128-cmp2-runnable.c), the instruction
>>> xscmpexpqp is used to support a few builtins e.g.
>>> __builtin_vsx_scalar_cmp_exp_qp_eq on _Float128.
>>> This instruction handles the whole 128bits of the vector, and
>>> it is guarded by [ieee128-hw].
>>
>> The instruction xscmpexpqp is guarded with TARGET_P9_VECTOR,
>>
>> (define_insn "*xscmpexpqp"
>> [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
>> (compare:CCFP
>> (unspec:IEEE128 [(match_operand:IEEE128 1 "altivec_register_operand"
>> "v")
>> (match_operand:IEEE128 2 "altivec_register_operand" "v")]
>> UNSPEC_VSX_SCMPEXPQP)
>> (match_operand:SI 3 "zero_constant" "j")))]
>> "TARGET_P9_VECTOR"
>> "xscmpexpqp %0,%1,%2"
>> [(set_attr "type" "fpcompare")])
>>
>> [ieee128-hw] is used for guarding those bifs, so the above
>> statement doesn't quite match the fact.
>>
>
> Agree, I'm wondering if P9_VECTOR is perfect here, even if it indicates the
> ISA
> which contains xscmpexpqp. Let me have more checks.
>
>> PR108758 said this case doesn't fail with gcc-10 and gcc-11,
>> I wonder why it changes from gcc-12? The above define_insn
>> shows the underlying insns for these bifs just requires the
>> condition power9-vector. Could you have a further check?
>> Thanks.
>
> Thanks for raising this concern.
> The behavior to check about bif on FLOAT128_HW and emit an error message for
> requirements on quad-precision is added in gcc12. This is why gcc12 fails to
> compile the case on -m32.
>
> Before gcc12, altivec_resolve_overloaded_builtin will return the overloaded
> result directly, and does not check more about the result function.
Thanks for checking, I wonder which commit caused this behavior change and
what's
the underlying justification? I know there is one new bif handling framework
introduced in gcc12, not sure the checking condition was changed together or by
a standalone commit. Anyway, apparently the conditions for the support of these
bifs are different on gcc-11 and gcc-12, I wonder why it changed. As mentioned
above, PR108758's c#1 said this case (bifs) work well on gcc-11, I suspected the
condition change was an overkill, that's why I asked.
BR,
Kewen
>
>>
>> btw, please add a PR marker for PR108758.
>
> Sure, thanks for catching this!
>
>
> BR,
> Jeff (Jiufu)
>
>>
>> BR,
>> Kewen
>>
>>> So, we may update the testcase to require ppc_float128_hw.
>>>
>>> Tested on ppc64 both BE and LE.
>>> Is this ok for trunk?
>>>
>>> BR,
>>> Jeff (Jiufu)
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * gcc.target/powerpc/float128-cmp2-runnable.c: Update requires.
>>>
>>> ---
>>> gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
>>> b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
>>> index d376a3ca68e..91287c0fb7a 100644
>>> --- a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
>>> @@ -1,5 +1,5 @@
>>> /* { dg-do run } */
>>> -/* { dg-require-effective-target ppc_float128_sw } */
>>> +/* { dg-require-effective-target ppc_float128_hw } */
>>> /* { dg-require-effective-target p9vector_hw } */
>>> /* { dg-options "-O2 -mdejagnu-cpu=power9 " } */
>>>
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Hi Kewen,
Thanks a lot for your very helpful comments!
On 2023-04-10 17:26, Kewen.Lin wrote:
Hi Jeff,
on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
Hi,
In this test case (float128-cmp2-runnable.c), the instruction
xscmpexpqp is used to support a few builtins e.g.
__builtin_vsx_scalar_cmp_exp_qp_eq on _Float128.
This instruction handles the whole 128bits of the vector, and
it is guarded by [ieee128-hw].
The instruction xscmpexpqp is guarded with TARGET_P9_VECTOR,
(define_insn "*xscmpexpqp"
[(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
(compare:CCFP
(unspec:IEEE128 [(match_operand:IEEE128 1 "altivec_register_operand"
"v")
(match_operand:IEEE128 2 "altivec_register_operand"
"v")]
UNSPEC_VSX_SCMPEXPQP)
(match_operand:SI 3 "zero_constant" "j")))]
"TARGET_P9_VECTOR"
"xscmpexpqp %0,%1,%2"
[(set_attr "type" "fpcompare")])
[ieee128-hw] is used for guarding those bifs, so the above
statement doesn't quite match the fact.
Agree, I'm wondering if P9_VECTOR is perfect here, even if it indicates
the ISA
which contains xscmpexpqp. Let me have more checks.
PR108758 said this case doesn't fail with gcc-10 and gcc-11,
I wonder why it changes from gcc-12? The above define_insn
shows the underlying insns for these bifs just requires the
condition power9-vector. Could you have a further check?
Thanks.
Thanks for raising this concern.
The behavior to check about bif on FLOAT128_HW and emit an error message
for
requirements on quad-precision is added in gcc12. This is why gcc12
fails to
compile the case on -m32.
Before gcc12, altivec_resolve_overloaded_builtin will return the
overloaded
result directly, and does not check more about the result function.
btw, please add a PR marker for PR108758.
Sure, thanks for catching this!
BR,
Jeff (Jiufu)
BR,
Kewen
So, we may update the testcase to require ppc_float128_hw.
Tested on ppc64 both BE and LE.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/float128-cmp2-runnable.c: Update requires.
---
gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
index d376a3ca68e..91287c0fb7a 100644
--- a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-require-effective-target ppc_float128_sw } */
+/* { dg-require-effective-target ppc_float128_hw } */
/* { dg-require-effective-target p9vector_hw } */
/* { dg-options "-O2 -mdejagnu-cpu=power9 " } */
Re: [PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Hi Jeff,
on 2023/4/10 10:09, Jiufu Guo via Gcc-patches wrote:
> Hi,
>
> In this test case (float128-cmp2-runnable.c), the instruction
> xscmpexpqp is used to support a few builtins e.g.
> __builtin_vsx_scalar_cmp_exp_qp_eq on _Float128.
> This instruction handles the whole 128bits of the vector, and
> it is guarded by [ieee128-hw].
The instruction xscmpexpqp is guarded with TARGET_P9_VECTOR,
(define_insn "*xscmpexpqp"
[(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
(compare:CCFP
(unspec:IEEE128 [(match_operand:IEEE128 1 "altivec_register_operand"
"v")
(match_operand:IEEE128 2 "altivec_register_operand"
"v")]
UNSPEC_VSX_SCMPEXPQP)
(match_operand:SI 3 "zero_constant" "j")))]
"TARGET_P9_VECTOR"
"xscmpexpqp %0,%1,%2"
[(set_attr "type" "fpcompare")])
[ieee128-hw] is used for guarding those bifs, so the above
statement doesn't quite match the fact.
PR108758 said this case doesn't fail with gcc-10 and gcc-11,
I wonder why it changes from gcc-12? The above define_insn
shows the underlying insns for these bifs just requires the
condition power9-vector. Could you have a further check?
Thanks.
btw, please add a PR marker for PR108758.
BR,
Kewen
> So, we may update the testcase to require ppc_float128_hw.
>
> Tested on ppc64 both BE and LE.
> Is this ok for trunk?
>
> BR,
> Jeff (Jiufu)
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/powerpc/float128-cmp2-runnable.c: Update requires.
>
> ---
> gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
> b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
> index d376a3ca68e..91287c0fb7a 100644
> --- a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
> +++ b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
> @@ -1,5 +1,5 @@
> /* { dg-do run } */
> -/* { dg-require-effective-target ppc_float128_sw } */
> +/* { dg-require-effective-target ppc_float128_hw } */
> /* { dg-require-effective-target p9vector_hw } */
> /* { dg-options "-O2 -mdejagnu-cpu=power9 " } */
>
[PATCH] testsuite: update requires for powerpc/float128-cmp2-runnable.c
Hi,
In this test case (float128-cmp2-runnable.c), the instruction
xscmpexpqp is used to support a few builtins e.g.
__builtin_vsx_scalar_cmp_exp_qp_eq on _Float128.
This instruction handles the whole 128bits of the vector, and
it is guarded by [ieee128-hw].
So, we may update the testcase to require ppc_float128_hw.
Tested on ppc64 both BE and LE.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/float128-cmp2-runnable.c: Update requires.
---
gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
index d376a3ca68e..91287c0fb7a 100644
--- a/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/float128-cmp2-runnable.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-require-effective-target ppc_float128_sw } */
+/* { dg-require-effective-target ppc_float128_hw } */
/* { dg-require-effective-target p9vector_hw } */
/* { dg-options "-O2 -mdejagnu-cpu=power9 " } */
--
2.31.1
