Segher,
Does BCD comparison return false when either operand is invalid coding?
If yes, the result could be 3-way. We can check gt and eq bits for ge.
We still can't use crnot to only check lt bit as there could be invalid
coding.
Also, do you think finite-math-only excludes invalid coding?
Hi,
This patch adds V1TI mode into a new mode iterator used in vector
comparison and rotation expands. Without the patch, the comparisons
between two vector __int128 are converted to scalar comparisons. The
code is suboptimal. The patch fixes the issue. Now all comparisons
between two vector
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595164.html
Thanks.
On 18/5/2022 下午 4:52, HAO CHEN GUI wrote:
> Hi,
> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
> Tests show that outputs of xs[min/max]dp are consistent with the
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595661.html
Thanks.
On 26/5/2022 下午 3:35, HAO CHEN GUI wrote:
> Hi,
> This patch fixes the ICE reported in PR100736. It removes the condition
> check of finite math only flag not setting in "
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate
Hi,
On 21/6/2022 上午 7:08, Segher Boessenkool wrote:
> && !flag_trapping_math
>
> and/or whatever else is needed as well here.
>
I have a question here. fmin/max are folded to MIN/MAX_EXPR when
flag_finite_math_only is set. Seems no-trapping-math is no need to
fmin/max? Also xs[min|max]dp do
Hi,
This patch uses CC instead of CCFP for all BCD operations. Thus, infinite
math flag has no impact on BCD operations. To support BCD overflow and
invalid coding, an UNSPEC is defined to move the bit to a general register.
The patterns of condition branch and return with overflow bit are
Hi,
This patch modifies the combine pattern after recog fails. With a helper
- change_pseudo_and_mask, it converts a single pseudo to the pseudo AND with
a mask when the outer operator is IOR/XOR/PLUS and inner operator is ASHIFT
or AND. The conversion helps pattern to match rotate and mask insn
Hi,
This patch fails TImode for all 128-bit logical operation expanders. So
TImode splits to two DI registers during expand. Potential optimizations can
be taken after expand pass. Originally, the TImode logical operations are
split after reload pass. It's too late. The test case illustrates it.
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597158.html
Thanks.
On 24/6/2022 上午 10:02, HAO CHEN GUI wrote:
> Hi,
> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
> Tests show that outputs of xs[min/max]dp are c
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597020.html
Thanks.
On 22/6/2022 下午 4:26, HAO CHEN GUI wrote:
> Hi,
> This patch uses CC instead of CCFP for all BCD operations. Thus, infinite
> math flag has no impact on BCD operations. To support BCD
Hi, Segher
On 8/7/2022 上午 1:31, Segher Boessenkool wrote:
>> --- a/gcc/testsuite/gcc.target/powerpc/rlwimi-2.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/rlwimi-2.c
>> @@ -2,14 +2,14 @@
>> /* { dg-options "-O2" } */
>>
>> /* { dg-final { scan-assembler-times {(?n)^\s+[a-z]} 14121 { target ilp32
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate
Hi,
On 7/6/2022 下午 11:59, Segher Boessenkool wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr93453-1.c
>> @@ -0,0 +1,14 @@
>> +/* { dg-do compile { target lp64 } } */
>> +/* { dg-options "-mdejagnu-cpu=power6 -O2" } */
> It doesn't require -m64, only -mpowerpc64. You can use
On 9/6/2022 下午 11:07, Segher Boessenkool wrote:
> Ah, good. Should we then have an assert that there is no fast-math if
> we ever get the rtl fmin/fmax stuff?
Sure, I will add a condition for it. Thanks a lot.
Gui Haochen
Hi,
On 2/6/2022 上午 5:01, Segher Boessenkool wrote:
> Hi!
>
> Some more nitpicking...
>
> On Wed, May 18, 2022 at 04:52:26PM +0800, HAO CHEN GUI wrote:
>>const double __builtin_vsx_xsmaxdp (double, double);
>> -XSMAXDP smaxdf3 {}
>> +XSMAXDP
Hi,
This patch replaces shift and ior insns with one rotate and mask
insn for the split patterns which are for DI byte swap on Power6. The
test cases shows the optimization.
Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations?
On 2/6/2022 下午 5:04, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 02, 2022 at 01:30:04PM +0800, HAO CHEN GUI wrote:
>> Segher,
>> Does BCD comparison return false when either operand is invalid coding?
>
> It sets all of LT, GT, and EQ to 0 (it normally sets
Hi,
This patch replaces shift and ior insns with one rotate and mask
insn for the split patterns which are for DI byte swap on Power6 and
before. The test cases shows the optimization.
Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any
Hi,
This patch uses CC instead of CCFP for all BCD operations. Thus, infinite
math flag has no impact on BCD operations. To support BCD overflow and
invalid coding, ordered and unordered are added into CC mode. With CC,
"ge" and "le" are converted to reverse comparison. So the invalid coding
Hi,
On 16/6/2022 下午 7:24, Segher Boessenkool wrote:
> There is no normal way to get at bit 3 of a CR field. We can use some
> unspec though, which is total cheating but it does work, and it is
> safe, albeit sometimes suboptimal.
Thanks so much for your advice. I will use an unspec for setting
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate
Hi,
On 8/6/2022 下午 9:24, Segher Boessenkool wrote:
> But it regresses the code quality generated with -ffast-math (because
> the new unspecs arent't optimised like standard rtl is). This can be
> follow-up work of course -- and the best direction is to make fmin/fmax
> generic, even! :-)
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate
Hi,
This patch adds an expand and several insns for multiply-add with
three 64bit operands.
Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.
ChangeLog
2022-07-22 Haochen Gui
gcc/
PR target/103109
Hi,
This patch creates a new function - change_pseudo_and_mask. If recog fails,
the function converts a single pseudo to the pseudo AND with a mask if the
outer operator is IOR/XOR/PLUS and inner operator is ASHIFT or AND. The
conversion helps pattern to match rotate and mask insn on some
Hi Segher,
Thanks for your comments.
On 13/7/2022 上午 1:26, Segher Boessenkool wrote:
>> --- a/gcc/config/rs6000/rs6000.md
>> +++ b/gcc/config/rs6000/rs6000.md
>> @@ -7078,27 +7078,38 @@ (define_expand "subti3"
>> })
>>
>> ;; 128-bit logical operations expanders
>> +;; Fail TImode in all
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a
Hi,
This patch skips constant folding for fmin/max when either argument
is sNaN. According to C standard,
fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) = qNaN
So signaling NaN should be tested and skipped for fmin/max in match.pd.
The V2 patch splits the for loop and keeps MIN/MAX_EXPR
On 5/5/2022 下午 4:30, Kewen.Lin wrote:
> on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote:
>> On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches
>> wrote:
>>>
>>> Hi,
>>>This patch skips constant folding for fmin/max when either arg
Hi,
This patch skips constant folding for fmin/max when either argument
is sNaN. According to C standard,
fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) = qNaN
So signaling NaN should be tested and skipped for fmin/max in match.pd.
Bootstrapped and tested on ppc64 Linux BE and LE with no
Hi,
On 24/8/2022 下午 1:24, Kewen.Lin wrote:
> Could you try to test with dg-options "-mdejagnu-cpu=power9 -mpowerpc64" all
> the time, but still
> having that has_arch_ppc64 effective target on aix?
>
> I'd expect has_arch_ppc64 check to fail on aix 32bit, the error will not be a
> problem
Hi,
This patch changes the sequence of test directives for 3 test cases.
Originally, these 3 cases got failed or unsupported on some platforms, as
their effective target checks depend on compiling options.
Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
Is this okay
Hi Segher,
Thanks for your review comments. I will refine it according to
your comments.
On 2/9/2022 上午 12:07, Segher Boessenkool wrote:
>> +/* { dg-do compile { target { ! has_arch_pwr9 } } } */
> Please keep dg-do first thing in the file.
Could you inform me if it's a must to put dg-do in the
Hi Kewen,
On 1/9/2022 下午 5:34, Kewen.Lin wrote:
> Thanks for the updated patch!
>
> I just found that it seems all the three test cases suffer the empty
> TU error issue from those has_arch* effective target checks?
>
> If yes, it looks we don't need to bother this once patch [1] gets
> landed?
Hi,
This patch is for internal issue1136. It changes insn condition from
TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions.
These instructions all use DI registers and can be invoked with -mpowerpc64
in a 32-bit environment.
This patch also changes prototypes of
Hi,
For scalar extract/insert instructions, exponent field can be stored in a
32-bit register. So this patch changes the mode of exponent field from DI to
SI. The instructions using DI registers can be invoked with -mpowerpc64 in a
32-bit environment. The patch changes insn condition from
Hi Segher,
On 23/8/2022 下午 10:26, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Aug 19, 2022 at 10:35:54AM +0800, HAO CHEN GUI wrote:
>> --- a/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-0.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-ex
Hi Kewen,
On 24/8/2022 下午 1:24, Kewen.Lin wrote:
> Could you try to test with dg-options "-mdejagnu-cpu=power9 -mpowerpc64" all
> the time, but still
> having that has_arch_ppc64 effective target on aix?
>
> I'd expect has_arch_ppc64 check to fail on aix 32bit, the error will not be a
>
Hi,
This patch is for internal issue1136. It changes insn condition from
TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions.
These instructions all use DI registers and can be invoked with -mpowerpc64
in a 32-bit environment.
This patch also changes prototypes of
Hi David,
On 25/8/2022 下午 10:01, David Edelsohn wrote:
> On Thu, Aug 25, 2022 at 1:22 AM Kewen.Lin wrote:
>>
>> on 2022/8/25 11:37, HAO CHEN GUI wrote:
>>> Hi,
>>>
>>> On 24/8/2022 下午 1:24, Kewen.Lin wrote:
>>>> Could you try to test with d
Hi,
This patch changes the sequence of test directives for 3 cases. Originally,
these 3 cases got failed or unsupported on some platforms, as their target
selector checks depend on compiling options.
Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
Is this okay for
Hi Kewen,
On 19/8/2022 上午 11:01, Kewen.Lin wrote:
> Maybe we should add one comment here (also the other touched case) or
> in the commit log saying why we reorder the dg-require-effective-target
> and dg-options, since the reason isn't obvious. :)
Sure, I will explain it in commit log. I
Hi,
This patch implements V8HI byte reverse on Power8 by vector rotation.
It should be effecient than orignial vector permute. The patch comes from
Xionghu's comments in PR. I just added a test case for it.
Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597158.html
Thanks.
On 1/8/2022 上午 10:03, HAO CHEN GUI wrote:
> Hi,
>Gentle ping this:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597158.html
> Thanks.
>
>
> On 4/7/2022 下午 2:3
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597020.html
Thanks.
On 1/8/2022 上午 10:02, HAO CHEN GUI wrote:
> Hi,
> Gentle ping this:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597020.html
> Thanks.
>
> On 4/7/2022 下午 2:33,
Hi,
This patch adds a new insn for vector splat with small V2DI constants on P8.
If the value of constant is in RANGE (-16, 15) and not 0 or -1, it can be loaded
with vspltisw and vupkhsw on P8. It should be efficient than loading vector from
TOC.
Bootstrapped and tested on powerpc64-linux BE
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601196.html
Thanks.
On 7/9/2022 下午 3:44, HAO CHEN GUI wrote:
> Hi,
>
> For scalar extract/insert instructions, exponent field can be stored in a
> 32-bit register. So this patch changes the mode
Hi Segher,
On 10/9/2022 上午 1:17, Segher Boessenkool wrote:
>> In rs6000-overload.def, the vsx_ version built-ins are overridden to vec_
>> version.
> How? Where?
vec_ version built-ins are defined in rs6000-overload.def. Yes, they're fine
and in line with the definition in PVIPR.
[VEC_VEEDP,
Hi Segher,
On 7/9/2022 上午 1:19, Segher Boessenkool wrote:
> make -k -j60 check
> RUNTESTFLAGS="--target_board=unix'{-m64,-m32,-m32/-mpowerpc64}'"
>
> It is fine to not test -m32/-mpowerpc64 so often, and certaionly not
> something I will ask everyone to always do :-)
IMO, if we add
On 7/9/2022 下午 10:25, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 07, 2022 at 08:51:17AM -0500, Paul A. Clarke wrote:
>> On Tue, Sep 06, 2022 at 12:19:06PM -0500, Segher Boessenkool wrote:
>>> On Mon, Sep 05, 2022 at 02:36:30PM +0800, HAO CHEN GUI wrote:
>
Hi Kewen & Segher,
Thanks so much for your review comments.
On 22/9/2022 上午 10:28, Kewen.Lin wrote:
> on 2022/9/22 05:56, Segher Boessenkool wrote:
>> Hi!
>>
>> On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
>>> This patch also binds __bui
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max when fast-math is not set. While fast-math
Hi,
This patch modifies the help function which generates permute index for
vector byte reversion and generates permute index directly for little endian
targets. It saves one "xxlnor" instructions on P8 little endian targets as
the original process needs an "xxlnor" to calculate complement for
Hi Segher,
Thanks for your review comments.
On 2/9/2022 下午 11:56, Segher Boessenkool wrote:
>> - const signed long __builtin_vsx_scalar_extract_exp (double);
>> + const unsigned long long __builtin_vsx_scalar_extract_exp (double);
>> VSEEDP xsxexpdp {}
>>
>> - const signed long
Hi Segher,
Thanks so much for your explanation. Now I have a clear picture about
the usage of return value. Patch was committed as r13-1971.
Thanks
Gui Haochen
On 5/8/2022 上午 1:09, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 04, 2022 at 05:55:20PM +0800, HAO CHEN
Hi Segher,
On 4/8/2022 上午 12:54, Segher Boessenkool wrote:
> Hrm. But the maddld insn is useful for SImode as well, in 32-bit mode,
> it is just its name that is a bit confusing then. Sorry for confusing
> things :-(
>
> Add a test for SImode maddld as well?
Thanks for your comments.
Just
:
> Hi!
>
> On Mon, Aug 08, 2022 at 02:04:07PM +0800, HAO CHEN GUI wrote:
>> This patch adds an expand and several insns for multiply-add with three
>> 64bit operands.
>
> Also for maddld for 32-bit operands.
>
>>"maddld %0,%1,%2,%3"
>>
Hi,
This patch adds an expand and several insns for multiply-add with three
64bit operands.
Compared with last version, the main changes are:
1 The "maddld" pattern is reused for the low-part generation.
2 A runnable testcase replaces the original compiling case.
3 Fixes indention problems.
Hi Segher,
Really appreciate your review comments.
On 11/8/2022 上午 1:38, Segher Boessenkool wrote:
> Hi!
>
> Sorry for the tardiness.
>
> On Fri, Jul 22, 2022 at 03:07:55PM +0800, HAO CHEN GUI wrote:
>> This patch creates a new function - change_pseudo_and
Hi Segher,
On 12/8/2022 上午 1:40, Segher Boessenkool wrote:
> Yes, but combine will use splitters as well.
Combine pass invokes combine_split_insns for 3-insn combine. If we want
to do the split for 2-insn combine (like the test case in PR), we have to
add a special case?
>
> You can use
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598744.html
Thanks
On 25/7/2022 下午 1:11, HAO CHEN GUI wrote:
> Hi,
> This patch adds an expand and several insns for multiply-add with
> three 64bit operands.
>
> Bootstrapped and tested on powerpc64-
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598685.html
Thanks.
On 22/7/2022 下午 3:07, HAO CHEN GUI wrote:
> Hi,
> This patch creates a new function - change_pseudo_and_mask. If recog fails,
> the function converts a single pseudo to the pseudo AND wi
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597020.html
Thanks.
On 4/7/2022 下午 2:33, HAO CHEN GUI wrote:
> Hi,
>Gentle ping this:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597020.html
> Thanks.
>
> On 22/6/2022 下午 4:26, HAO CHE
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597158.html
Thanks.
On 4/7/2022 下午 2:32, HAO CHEN GUI wrote:
> Hi,
>Gentle ping this:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597158.html
> Thanks.
>
> On 24/6/2022 上午 10:02, HAO CHE
Hi,
This patch corrects return value of check_p9modulo_hw_available. It should
return 0 when p9modulo is supported.
Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.
ChangeLog
2022-08-04 Haochen Gui
Hi,
This patch changes the definition of TARGET_MADDLD and includes
TARGET_POWERPC64, since maddld is a 64 bit instruction.
maddld-1.c now checks "has_arch_ppc64". It depends on a patch which fixes
empty TU problem.
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598744.html
Hi,
This patch changes the mode of exponent to GPR in scalar insert exp
pattern, as the exponent can be put into a 32-bit register. Also the
condition check is changed from TARGET_64BIT to TARGET_POWERPC64.
The test cases are modified according to the changes of expand pattern.
Hi,
This patch changes the return type of __builtin_vsx_scalar_extract_sig
from const signed long to const signed long long, so that it can be called
with "-m32/-mpowerpc64" option. The bif needs TARGET_POWERPC64 instead of
TARGET_64BIT. So the condition check in the expander is changed.
The
Hi,
This patch changes the return type of __builtin_vsx_scalar_extract_exp
from const signed long to const signed int, as the exponent can be put in
a signed int. It is also inline with the external interface definition of
the bif. The mode of exponent operand in "xsxexpdp" is changed to GPR
Hi,
"ilp32" is used in these test cases to make sure test cases only run on a
32-bit environment. Unfortunately, these cases also run with
"-m32/-mpowerpc64" which causes unexpected errors. This patch changes the
target check to skip if "has_arch_ppc64" is set. So the test cases won't run
when
Hi,
This patch enables "have_cbranchcc4" on rs6000 by defining
a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc
to indicate if branch by CC bits is invalid or not. With this
flag enabled, some branches can be optimized to conditional
moves.
Compared to last version, the main
Hi,
It gets an assertion failure when targers don't support cbranchcc4 or
predicate check fails in prepare_cmp_insn. prepare_cmp_insn is a help
function to generate compare rtx, so it should not assume that cbranchcc4
is existing or all sub-CC modes are supported on one target. I think it
should
Hi Kewen,
在 2022/12/8 16:47, Kewen.Lin 写道:
> This documentation update reminds me of that the current prototype of
> __ieee128
> variant can be:
>
> unsigned int scalar_extract_exp (__ieee128 source);
>
> type unsigned int is enough for the exponent. It means xsxexpqp_ can
> also
> use
Hi Richard,
在 2022/12/5 15:31, Richard Biener 写道:
> I wonder if you have a testcase you can add showing this change is
> worthwhile and
> fixes a bug?
I want to enable cbranchcc4 on rs6000. But not all sub CCmode is
supported on rs6000. So the predicate check(assert) fails and it hits
ICE. I
Hi,
This patch adds a new conversion to convert a certain branch to
conditional ternary set in ifcvt.
The branch commonly has following insns.
cond_jump ? pc : label
setcc
(neg/subreg)
label: set a constant
cond_jump and setcc use the same CC reg and neg/subreg is optional.
The
Hi Kewen,
Thanks so much for your review comments. I will fix them.
在 2022/12/7 11:06, Kewen.Lin 写道:
> Does this issue which relies on the fix for generic part make bootstrapping
> fail?
> If no, how many failures it can cause? I'm thinking if we can commit this
> firstly,
> then in the
Hi,
This patch fixes several problems:
1. The exponent of double-precision can be put into a SImode register.
So "xsxexpdp" doesn't require 64-bit environment. Also "xsxsigdp",
"xsiexpdp" and "xsiexpdpf" can put exponent into a GPR register.
2. "TARGET_64BIT" check in insn
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601909.html
Thanks
Gui Haochen
在 2022/9/21 13:13, HAO CHEN GUI 写道:
> Hi,
> This patch adds a new insn for vector splat with small V2DI constants on P8.
> If the value of constant is in RANGE (-16, 15)
Hi,
This patch enables "have_cbranchcc4" on rs6000 by defining
a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc
to indicate if branch by CC bits is invalid or not. With this
flag enabled, some branches can be optimized to conditional
moves.
The patch relies on the former patch
Hi David,
在 2022/11/17 21:24, David Edelsohn 写道:
> This is better, but the pattern should be near and after the existing
> cbranch4 patterns earlier in the file, not the *cbranch pattern. It
> doesn't match the comment.
Sure, I will put it after existing "cbranch4" patterns.
>
> Why are you
Hi Segher,
Thanks for your comments.
在 2022/11/22 7:49, Segher Boessenkool 写道:
> *cbranch_2insn is not a machine insn. It generates a cror and a branch
> insn. This makes no sense to have in a cbranchcc: those do a branch
> based on an existing cr field, so based on the *output* of that cror.
Hi Kewen,
在 2022/11/22 11:11, Kewen.Lin 写道:
> Maybe we can adjust prepare_cmp_insn to fail if the constructed cbranchcc4
> pattern doesn't satisfy the predicate of operand 0 rather than to assert.
> It's something like:
>
> if (!insn_operand_matches (icode, 0, test))
> goto fail;
>
> or only
Hi Richard,
在 2022/11/24 4:06, Richard Biener 写道:
> Wouldn't we usually either add an optab or try to recog a canonical
> RTL form instead of adding a new target hook for things like this?
Thanks so much for your comments. Please let me make it clear.
Do you mean we should create an optab for
Hi Segher,
在 2022/11/18 20:18, Segher Boessenkool 写道:
> I don't think we should pretend we have any conditional jumps the
> machine does not actually have, in cbranchcc4. When would this ever be
> useful? cror;beq can be quite expensive, compared to the code it would
> replace anyway.
>
> If
Hi Richard,
在 2022/11/29 2:46, Richard Biener 写道:
> Anyhow - my question still stands - what's the fallback for the callers
> that do not check for failure? How are we sure we're not running into
> these when relaxing the requirement that a MODE_CC prepare_cmp_insn
> must not fail?
I examed the
Hi,
The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to
indicate if branch by CC bits is invalid or not. The new expand pattern
"cbranchcc4" is created which intend to match the pattern defined in
"*cbranch", "*cbranch_2insn" and "*creturn". The operand sequence in
"cbranchcc4" is
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607083.html
Thanks
Gui Haochen
在 2022/11/23 10:54, HAO CHEN GUI 写道:
> Hi,
> I want to enable "have_cbranchcc4" on rs6000. But not all combinations of
> comparison codes and sub CC modes are be
Hi Nilsson,
在 2022/12/2 10:49, Hans-Peter Nilsson 写道:
> On Wed, 23 Nov 2022, HAO CHEN GUI via Gcc-patches wrote:
>
>> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
>> index 92bda1a7e14..9823eccbe68 100644
>> --- a/gcc/doc/tm.texi
>> +++ b/gcc/doc/tm.texi
>&
Hi,
For scalar extract/insert instructions, exponent field can be stored in a
32-bit register. So this patch changes the mode of exponent field from DI to
SI so that these instructions can be generated in a 32-bit environment. Also
it removes TARGET_64BIT check for these instructions.
The
Hi,
I want to enable "have_cbranchcc4" on rs6000. But not all combinations of
comparison codes and sub CC modes are benefited to generate cbranchcc4 insns
on rs6000. There is an predicate for operand0 of cbranchcc4 to bypass
some combinations. It gets assertion failure in prepare_cmp_insn. I
Hi,
There is a new insn on my target, which has a nested if_then_else and
set -1, 0 and 1 according to a comparison.
[(set (match_operand:SI 0 "gpc_reg_operand" "=r")
(if_then_else:SI (lt (match_operand:CC 1 "cc_reg_operand" "y")
(const_int 0))
Hi,
The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to
indicate if branch by CC bits is invalid or not. As rs6000 already has
"*cbranch" insn which does branching according to CC bits, the flag
should be enabled and relevant branches can be optimized out. The test
case illustrates
Hi David,
I found definition of the operands in 'cbranch'. The argumnets matters.
I will create a new expand pattern for cbranchcc4. Thanks a lot for your
comments.
'cbranchmode4’
Conditional branch instruction combined with a compare instruction.
Operand 0 is a comparison operator. Operand 1
Hi,
When TI AND with a special constant (the high part or low part is all
ones), it may be converted to DI AND with a 64-bit constant and a simple
DI move. When the DI AND can be implemented by rotate and mask or
"andi.", it eliminates the 128-bit constant loading to save the cost.
The patch
Hi,
For scalar extract/insert instructions, exponent field can be stored in a
32-bit register. So this patch changes the mode of exponent field from DI to
SI. So these instructions can be generated in a 32-bit environment. The patch
removes TARGET_64BIT check for these instructiions.
The
Hi Kewen,
I tested it with my fortran test case. It works. Thanks a lot.
Gui Haochen
在 2023/3/6 17:27, Kewen.Lin 写道:
> Hi,
>
> According to Haochen's finding in [1], currently ppc-fortran.exp
> doesn't support Fortran specific warning or error messages well.
> By looking into it, it's due to
Hi,
The patch escalates the failure when Hollerith constant to real conversion
fails in native_interpret_expr. It finally reports an "Cannot simplify
expression" error in do_simplify method.
The patch of pr95450 added a verification for decoding/encoding checking
in native_interpret_expr.
Hi Richard,
在 2023/3/16 18:36, Richard Biener 写道:
> On Thu, Mar 16, 2023 at 10:04 AM HAO CHEN GUI wrote:
>>
>> Hi Richard,
>>
>> 在 2023/3/16 15:57, Richard Biener 写道:
>>> So this is one way around the lack of CSE/PRE of constant operands. I'd
>>> arg
301 - 400 of 449 matches
Mail list logo
