Segher Boessenkool writes:
Hi,
Thanks for all your comments!
> Hi!
>
> On Wed, Apr 15, 2020 at 08:21:03AM +0200, Richard Biener wrote:
>> On Wed, Apr 15, 2020 at 3:56 AM Jiufu Guo via Gcc-patches
>> wrote:
>> > As you may know, we have loop unroll pass in
Segher Boessenkool writes:
> Hi Jiufu,
>
> Just reviewing random things as I see them...
>
> On Wed, Apr 15, 2020 at 09:56:00AM +0800, Jiufu Guo wrote:
>> This patch only supports simple loops: one exit edge with one major basic
>> block.
>
> That is fine for a proof-of-concept, but will need
Hi,
As you may know, we have loop unroll pass in RTL which was introduced a few
years ago, and works for a long time. Currently, this unroller is using the
pseudos in the original body, and then the pseudos are written multiple times.
It would be a good idea to create new pseudos for those
Matthias Klose writes:
Thanks so much for all of you for pay attention and take care of
this. Matthias and Segher point out this; Joseph helped remove this
file. Sorry for spend your extra time on this.
Thanks again!
> diff --git a/a b/a
> new file mode 100644
> index
Jiufu Guo writes:
Hi,
I'd like to ping this patch for trunk on stage 1.
This patch could fix the issue on incorrect COUNT/FREQUENCES of loop
unrolled blocks, and also could help the improve the cold/hot issue of
the unrolled loops.
patch is also at
Jiufu Guo writes:
Hi!
I'd like to ping following patch. As near end of gcc10 stage 4, it seems
I would ask approval for GCC11 trunk.
Thanks,
Jiufu Guo
> Hi Honza and all,
>
> I updated the patch a little as below. Bootstrap and regtest are ok
> on powerpc64le.
>
> Is OK for trunk?
>
> Thanks
Jiufu Guo writes:
Backported to GCC 9, preapproved by Segher.
Thanks,
Jiufu
> Segher Boessenkool writes:
>
>> Hi!
>>
>> On Thu, Mar 05, 2020 at 10:46:58AM +0800, Jiufu Guo wrote:
>>> PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
>>> relates to max of '-inf' and
Segher Boessenkool writes:
> On Wed, May 20, 2020 at 12:30:30PM +0200, Richard Biener wrote:
>> I think this is the wrong way to approach this. You're doing too many
>> things at once. Try to fix the powerpc regression with the extra
>> flag_rtl_unroll_loops, that could be backported. Then
Hi,
In r10-4525, and r10-4161, loop unroller was enabled for simply loops at -O2.
At the same time, the GIMPLE cunroll is also enabled, while it is not only for
simple loops. This patch introduces a hook to check if a loop is suitable to
unroll completely. The hook can be used to check if a
Jiufu Guo writes:
> Hi,
>
> This patch check the size of a loop to be unrolled/peeled completely,
> and set the limits to a number (24). This prevents large loop from
> being unrolled, then avoid binary size increasing, and this limit keeps
> performance.
>
> Bootstrap pass on powerpc64le, ok
Hi,
This patch check the size of a loop to be unrolled/peeled completely,
and set the limits to a number (24). This prevents large loop from
being unrolled, then avoid binary size increasing, and this limit keeps
performance.
Bootstrap pass on powerpc64le, ok for trunk?
Jiufu
---
Jan Hubicka writes:
>> Segher Boessenkool writes:
>>
>> > On Wed, May 20, 2020 at 12:30:30PM +0200, Richard Biener wrote:
>> >> I think this is the wrong way to approach this. You're doing too many
>> >> things at once. Try to fix the powerpc regression with the extra
>> >>
Jiufu Guo writes:
> Jan Hubicka writes:
>
>>> Segher Boessenkool writes:
>>>
>>> > On Wed, May 20, 2020 at 12:30:30PM +0200, Richard Biener wrote:
>>> >> I think this is the wrong way to approach this. You're doing too many
>>> >> things at once. Try to fix the powerpc regression with the
guojiufu writes:
Hi,
In this patch, the default value of
param=max-unrolled-average-calls-x1 is '0', which means to unroll
a loop, there should be no call inside the body. Do I need to set the
default value to a bigger value (16?) for later tune? Biger value will
keep the behavior
Hi all,
This patch sets the default value to 16 for parameter
max_unrolled_average_calls which could be used to restict calls in loop
when unrolling. This default value(16) is a big number which keeps
current behavior for almost all cases.
Bootstrap and regtest pass on powerpc64le. Is this ok
On 2020-08-24 19:16, Jan Hubicka wrote:
On Thu, Aug 20, 2020 at 6:35 AM guojiufu via Gcc-patches
wrote:
>
> Hi,
>
> This patch is checking the _average_ number of calls which is the
> summary of call numbers multiply the possibility of the call maybe
> executed. The _average_ number could be a
Richard Biener writes:
> On Wed, May 27, 2020 at 6:36 AM Jiufu Guo wrote:
>>
>> Segher Boessenkool writes:
>>
>> > Hi!
>> >
>> > On Tue, May 26, 2020 at 08:58:13AM +0200, Richard Biener wrote:
>> >> On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool
>> >> wrote:
>> >> > Yes, cunroll does not
David Edelsohn writes:
> On Mon, May 25, 2020 at 1:58 PM Richard Biener
> wrote:
>>
>> On May 25, 2020 7:40:00 PM GMT+02:00, Segher Boessenkool
>> wrote:
>> >On Mon, May 25, 2020 at 02:14:02PM +0200, Richard Biener wrote:
>> >> On Mon, May 25, 2020 at 1:10 PM guojiufu
>> >wrote:
>> >> Since
Richard Biener writes:
> On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool
> wrote:
>>
>> On Mon, May 25, 2020 at 02:39:54PM +0200, Richard Biener wrote:
>> > On Fri, May 22, 2020 at 6:54 PM Segher Boessenkool
>> > wrote:
>> > > > The split above allows the "bug" to be fixed (even on the
Richard Biener writes:
> On Thu, May 28, 2020 at 10:52 AM guojiufu wrote:
>>
>> From: Jiufu Guo
>>
>> Currently GIMPLE complete unroller(cunroll) is checking
>> flag_unroll_loops and flag_peel_loops to see if allow size growth.
>> Beside affects curnoll, flag_unroll_loops also controls RTL
Richard Biener writes:
> On Thu, May 28, 2020 at 4:37 PM Jiufu Guo wrote:
>>
>> Richard Biener writes:
>>
>> > On Thu, May 28, 2020 at 10:52 AM guojiufu wrote:
>> >>
>> >> From: Jiufu Guo
>> >>
>> >> Currently GIMPLE complete unroller(cunroll) is checking
>> >> flag_unroll_loops and
Segher Boessenkool writes:
> Hi!
>
> On Thu, May 28, 2020 at 04:22:16PM +0200, Richard Biener wrote:
>> For GIMPLE level transforms I don't think targets have more knowledge
>> than the middle-end.
>
> Yes, certainly.
>
>> In fact GIMPLE complete unrolling is about
>> secondary effects, removing
Jiufu Guo writes:
Hi,
I updated the patch just a little accordinlgy. Thanks!
diff --git a/gcc/common.opt b/gcc/common.opt
index 4464049fc1f..570e2aa53c8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2856,6 +2856,10 @@ funroll-all-loops
Common Report Var(flag_unroll_all_loops)
Segher Boessenkool writes:
> Hi!
>
> On Tue, May 26, 2020 at 08:58:13AM +0200, Richard Biener wrote:
>> On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool
>> wrote:
>> > Yes, cunroll does not have its own option, and that is a problem. But
>> > that is easy to fix! Either with an option, or
"Kewen.Lin" writes:
> Hi Jeff,
>
> on 2020/5/20 上午11:58, Jiufu Guo via Gcc-patches wrote:
>> Hi,
>>
>> This patch check the size of a loop to be unrolled/peeled completely,
>> and set the limits to a number (24). This prevents large loop fro
Richard Biener writes:
> On Wed, May 20, 2020 at 5:56 AM Jiufu Guo via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> In r10-4525, and r10-4161, loop unroller was enabled for simply loops at -O2.
>> At the same time, the GIMPLE cunroll is also enabled, while it
Richard Biener writes:
> On Wed, May 20, 2020 at 5:56 AM Jiufu Guo via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> In r10-4525, and r10-4161, loop unroller was enabled for simply loops at -O2.
>> At the same time, the GIMPLE cunroll is also enabled, while it
Richard Biener writes:
> On Wed, May 20, 2020 at 10:27 AM Jiufu Guo wrote:
>>
>> Richard Biener writes:
>>
>> > On Wed, May 20, 2020 at 5:56 AM Jiufu Guo via Gcc-patches
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >&
Segher Boessenkool writes:
Thanks all!
> Hi!
>
> On Mon, Jul 06, 2020 at 03:13:13PM +0800, guojiufu wrote:
>> For very small loops (< 6 insns), it would be fine to unroll 4
>> times to use cache line better. Like below loops:
>> `while (i) a[--i] = NULL; while (p < e) *d++ = *p++;`
>
> Yes,
will schmidt writes:
Thanks!
> On Mon, 2020-07-06 at 15:13 +0800, guojiufu via Gcc-patches wrote:
>
> Hi,
>
> Assorted comments below. thanks :-)
>
>> For very small loops (< 6 insns), it would be fine to unroll 4
>> times to use cache line better. Like below loops:
>> `while (i) a[--i] =
Segher Boessenkool writes:
Hi,
> On Wed, Jul 08, 2020 at 11:39:56AM +0800, Jiufu Guo wrote:
>> Segher Boessenkool writes:
>> > I am not happy about what is considered "a complex loop" here.
>> For early exit, which may cause and *next* unrolled iterations may be
>> not executed, then unroll
Hi Martin,
Martin Liška writes:
> On 7/10/20 4:14 AM, Jiufu Guo wrote:
>> Thanks so much for your time and kindly help!!!
>
> And I run your patch on SPEC2006 with:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549728.html
>
> Doing that I see just few changes:
>
> diff -qr
Hi,
Segher Boessenkool writes:
> Hi Jiufu,
>
> On Thu, Jul 09, 2020 at 04:01:38PM +0800, Jiufu Guo wrote:
>> Segher Boessenkool writes:
>> >> But for each single condition, loop unrolling may still be helpful.
>> >> While, if these conditions are all occur in a loop, it would be more
>> >>
Hi Segher,
Thanks a lot for your time and helpful comments!
Segher Boessenkool writes:
> Hi Jiufu,
>
> On Thu, Jul 09, 2020 at 04:01:38PM +0800, Jiufu Guo wrote:
>> Segher Boessenkool writes:
...
> If the generic code decides to unroll big loops with calls *and* jumps,
> there is a big
/gcc-patches/2020-02/msg00927.html
>
> BR,
> Jiufu Guo
>
>> Jiufu Guo via Gcc-patches writes:
>>
>> Hi,
>>
>> I would like to reping this, hope to get approval for this patch.
>> https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg00927.html
*b, long int n)
+{
+ long int i;
+
+ for (i = 0; i < n; i++)
+a[i] = *b;
+}
+
+/* { dg-final { scan-rtl-dump-times "internal loop alignment added" 1
"alignments"} } */
+
--
2.7.4
Thanks!
Jiufu Guo.
Martin Liška writes:
> On 7/2/20 4:35 AM, Jiufu Guo via Gcc-patc
Jiufu Guo writes:
Gentle ping.
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg00927.html
BR,
Jiufu Guo
> Jiufu Guo via Gcc-patches writes:
>
> Hi,
>
> I would like to reping this, hope to get approval for this patch.
> https://gcc.gnu.org/legacy-ml/gcc-patches/202
On 2020-06-05 01:53, Segher Boessenkool wrote:
On Thu, Jun 04, 2020 at 08:46:23AM +0200, Richard Biener wrote:
On Thu, Jun 4, 2020 at 5:34 AM Jiufu Guo
wrote:
> Patch is updated a little according to comments.
> Please see if this is ok to commit.
OK with a proper ChangeLog after bootstrap /
guojiufu writes:
> From: Jiufu Guo
>
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -4567,7 +4567,12 @@ rs6000_option_override_internal (bool global_init_p)
> unroll_only_small_loops = 0;
> if (!global_options_set.x_flag_rename_registers)
>
Jiufu Guo writes:
Hi,
Patch is updated a little according to comments.
Please see if this is ok to commit.
diff --git a/gcc/common.opt b/gcc/common.opt
index 4464049fc1f..570e2aa53c8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2856,6 +2856,10 @@ funroll-all-loops
Common Report
Richard Biener writes:
> On Tue, Jun 2, 2020 at 4:10 AM Jiufu Guo wrote:
>>
>> Jiufu Guo writes:
>>
>> Hi,
>>
>> I updated the patch just a little accordinlgy. Thanks!
>>
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index 4464049fc1f..570e2aa53c8 100644
>> --- a/gcc/common.opt
>> +++
Jiufu Guo via Gcc-patches writes:
Hi,
I would like to reping this, hope to get approval for this patch.
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-02/msg00927.html
BR,
Jiufu Guo
> Jiufu Guo writes:
>
> Hi,
>
> I'd like to ping this patch for trunk on stage 1.
>
>
Jiufu Guo writes:
> Jeff Law writes:
>
>> On 11/18/20 12:28 AM, Richard Biener wrote:
>>> On Tue, 17 Nov 2020, Jeff Law wrote:
>>>
Minor questions for Jan and Richi embedded below...
On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote:
> When investigating the issue from
Jiufu Guo writes:
> Jiufu Guo writes:
>
>> Jeff Law writes:
>>
>>> On 11/18/20 12:28 AM, Richard Biener wrote:
On Tue, 17 Nov 2020, Jeff Law wrote:
> Minor questions for Jan and Richi embedded below...
>
> On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote:
>> When
Jeff Law writes:
> On 11/18/20 12:28 AM, Richard Biener wrote:
>> On Tue, 17 Nov 2020, Jeff Law wrote:
>>
>>> Minor questions for Jan and Richi embedded below...
>>>
>>> On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote:
When investigating the issue from
Thanks a lot for the sugguestion from previous mails.
The patch was updated accordingly.
This updated patch propagates loop-closed PHIs them out after
loop_optimizer_finalize under a new introduced flag. At some cases,
to clean up loop-closed PHIs would save efforts of optimization passes
guojiufu writes:
Hi Honza, all,
Just want to ping this for review. Original messages:
[PATCH 2/2] https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555872.html
[PATCH 1/2] https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
Thanks,
Jiufu Guo.
> Hi,
> PR68212 mentioned that
Richard Biener writes:
> On Wed, 11 Nov 2020, Jiufu Guo wrote:
>
>>
>> Thanks a lot for the sugguestion from previous mails.
>> The patch was updated accordingly.
>>
>> This updated patch propagates loop-closed PHIs them out after
>> loop_optimizer_finalize under a new introduced flag. At
Jiufu Guo writes:
> Richard Biener writes:
>
>> On Wed, 11 Nov 2020, Jiufu Guo wrote:
>>
>>>
>>> Thanks a lot for the sugguestion from previous mails.
>>> The patch was updated accordingly.
>>>
>>> This updated patch propagates loop-closed PHIs them out after
>>> loop_optimizer_finalize under
On 2020-11-16 17:35, Richard Biener wrote:
On Mon, Nov 16, 2020 at 10:26 AM Jiufu Guo
wrote:
Jiufu Guo writes:
> Richard Biener writes:
>
>> On Wed, 11 Nov 2020, Jiufu Guo wrote:
>>
>>>
>>> Thanks a lot for the suggestion from previous mails.
>>> The patch was updated accordingly.
>>>
>>>
Jiufu Guo writes:
> On 2020-11-16 17:35, Richard Biener wrote:
>> On Mon, Nov 16, 2020 at 10:26 AM Jiufu Guo
>> wrote:
>>>
>>> Jiufu Guo writes:
>>>
>>> > Richard Biener writes:
>>> >
>>> >> On Wed, 11 Nov 2020, Jiufu Guo wrote:
>>> >>
..
>>> +
>>> + /* Check dominator info before get
On 2020-11-05 21:43, Richard Biener wrote:
Hi Richard,
Thanks for your comments and suggestions!
On Thu, Nov 5, 2020 at 2:19 PM guojiufu via Gcc-patches
wrote:
In PR87473, there are discussions about loop-closed PHIs which
are generated for loop optimization passes. It would be helpful
to
As discussed in the PR, Richard mentioned the method to
figure out which VAR was not set TREE_ADDRESSABLE, and
then cause this failure. It is address_expression which
build addr_expr (build_fold_addr_expr_loc), but not set
TREE_ADDRESSABLE.
I drafted this patch with reference the comments from
When there is the possibility that overflow/wrap may happen on the loop index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k != n)
a[k] = b[k] + 1;
}
For this code, if "k > n", k would wrap. if "k < n" at begining,
it
Update the patch since v2:
. Check index and bound from gcond before checking if wrap.
. Update test case, and add an executable case.
. Refine code comments.
. Enhance the checking for i++/++i in the loop header.
. Enhance code to handle equal condition on exit
Bootstrap and regtest pass on
Changes since v1:
* Update assumptions for niter, add more test cases check
* Use widest_int/wide_int instead mpz to do +-/
* Move some early check for quick return
For code like:
unsigned foo(unsigned val, unsigned start)
{
unsigned cnt = 0;
for (unsigned i = start; i > val; ++i)
cnt++;
For code like:
unsigned foo(unsigned val, unsigned start)
{
unsigned cnt = 0;
for (unsigned i = start; i > val; ++i)
cnt++;
return cnt;
}
The number of iterations should be about UINT_MAX - start.
There is function adjust_cond_for_loop_until_wrap which
handles similar work for const
Currently, doloop.xx variable is using the type as niter which may shorter
than word size. For some cases, it may be better to use word size type.
For example, on some 64bit system, to access 32bit niter, subreg maybe used.
Then using 64bit type would not need to use subreg if the value can be
When there is the possibility that overflow may happen on the loop index,
a few optimizations would not happen. For example code:
foo (int *a, int *b, unsigned k, unsigned n)
{
while (++k != n)
a[k] = b[k] + 1;
}
For this code, if "l > n", overflow may happen. if "l < n" at begining,
it
Richard Biener writes:
On Tue, 31 Aug 2021, guojiufu wrote:
On 2021-08-30 20:02, Richard Biener wrote:
> On Mon, 30 Aug 2021, guojiufu wrote:
>
>> On 2021-08-30 14:15, Jiufu Guo wrote:
>> > Hi,
>> >
>> > In patch r12-3136, niter->control, niter->bound and
>> > niter->cmp are
>> > derived
在 2021/9/1 上午11:30, Jiufu Guo via Gcc-patches 写道:
Richard Biener writes:
On Tue, 31 Aug 2021, guojiufu wrote:
On 2021-08-30 20:02, Richard Biener wrote:
> On Mon, 30 Aug 2021, guojiufu wrote:
> >> On 2021-08-30 14:15, Jiufu Guo wrote:
>> > Hi,
>> >
>>
Hi,
In patch r12-3136, niter->control, niter->bound and niter->cmp are
derived from number_of_iterations_lt. While for 'until wrap condition',
the calculation in number_of_iterations_lt is not align the requirements
on the define of them and requirements in determine_exit_conditions.
This patch
"Bin.Cheng" writes:
On Wed, Aug 4, 2021 at 10:42 AM guojiufu
wrote:
Hi,
cut...
>> @@ -0,0 +1,63 @@
>> +TYPE __attribute__ ((noinline))
>> +foo_sign (int *__restrict__ a, int *__restrict__ b, TYPE l,
>> TYPE n)
>> +{
>> + for (l = L_BASE; n < l; l += C)
>> +*a++ = *b++ + 1;
>> +
Jiufu Guo writes:
"Bin.Cheng" writes:
On Wed, Aug 4, 2021 at 10:42 AM guojiufu
wrote:
Hi,
cut...
>> @@ -0,0 +1,63 @@
>> +TYPE __attribute__ ((noinline))
>> +foo_sign (int *__restrict__ a, int *__restrict__ b, TYPE
>> l, >> TYPE n)
>> +{
>> + for (l = L_BASE; n < l; l += C)
>> +
Richard Biener writes:
> On Tue, 31 Aug 2021, guojiufu wrote:
>
>> On 2021-08-30 20:02, Richard Biener wrote:
>> > On Mon, 30 Aug 2021, guojiufu wrote:
>> >
>> >> On 2021-08-30 14:15, Jiufu Guo wrote:
>> >> > Hi,
>> >> >
>> >> > In patch r12-3136, niter->control, niter->bound and niter->cmp are
When transform
{iv0.base, iv0.step} LT/LE {iv1.base, iv1.step}
to
{iv0.base, iv0.step - iv1.step} LT/LE {iv1.base, 0}
There would be error if 'iv0.step - iv1.step' in negative,
for which means run until wrap/overflow.
For example:
{1, +, 1} <= {4, +, 3} => {1, +, -2} <= {4, +, 0}
This
Changes on V1:
* Add more test case
* Add comment for exit-condition transform
* Removing duplicate setting on niter->control
This patch reset niter->control, niter->bound and niter->cmp in
number_of_iterations_until_wrap.
Bootstrap and test pass on ppc64 and x86, and pass the test cases
in
Richard Biener writes:
> On Thu, 2 Sep 2021, Jiufu Guo wrote:
>
>> When transform
>> {iv0.base, iv0.step} LT/LE {iv1.base, iv1.step}
>> to
>> {iv0.base, iv0.step - iv1.step} LT/LE {iv1.base, 0}
>>
>> There would be error if 'iv0.step - iv1.step' in negative,
>> for which means run until
Jiufu Guo writes:
I may want to have a gentle ping on this.
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578680.html
BR,
Jiufu
> Changes on V1:
> * Add more test case
> * Add comment for exit-condition transform
> * Removing duplicate setting on niter->control
>
> This patch reset
Major changes from v1:
* Add target hook to query preferred doloop mode.
* Recompute doloop iv base from niter under preferred mode.
Currently, doloop.xx variable is using the type as niter which may shorter
than word size. For some cases, it would be better to use word size type.
For example,
Iain Sandoe writes:
On 15 Jul 2021, at 06:09, guojiufu via Gcc-patches
wrote:
On 2021-07-15 02:04, Segher Boessenkool wrote:
+@deftypefn {Target Hook} machine_mode
TARGET_PREFERRED_DOLOOP_MODE
(machine_mode @var{mode})
+This hook takes a @var{mode} which is the original mode of
doloop
Refine code for V2 according to review comments:
* Use if check instead assert, and refine assert
* Use better RE check for test case, e.g. (?n)/(?p)
* Use better wording for target.def
Currently, doloop.xx variable is using the type as niter which may be
shorter than word size. For some
In tree_simplify_using_condition_1, there is code which should be logic:
"op0 || op1"/"op0 && op1". When creating expression for TRUTH_OR_EXPR
and TRUTH_AND_EXPR, fold_build2 would be used instead fold_binary which
always return NULL_TREE for this kind of expr.
Bootstrap and regtest pass on ppc
With reference the discussions in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574334.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572006.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578672.html
Base on the patches in above discussion, we may draft a patch to
Hi,
Normaly, estimate_numbers_of_iterations get/caculate niter first,
and then invokes infer_loop_bounds_from_undefined. While in some case,
after a few call stacks, estimate_numbers_of_iterations is invoked before
niter is ready (e.g. before number_of_latch_executions returns).
e.g.
Richard Biener writes:
> On Mon, 1 Nov 2021, Jiufu Guo wrote:
>
>> PR101145 is supporting if the number of iterations can be calculated
>> for the 'until wrap' condition. Current test cases are checking if
>> the loop can be vectorized, if a loop can be vectorized then the number
>> of
Richard Biener writes:
> On Wed, 3 Nov 2021, Jiufu Guo wrote:
>
>> Richard Biener writes:
>>
>> > On Mon, 1 Nov 2021, Jiufu Guo wrote:
>> >
>> >> PR101145 is supporting if the number of iterations can be calculated
>> >> for the 'until wrap' condition. Current test cases are checking if
>> >>
Richard Biener writes:
> On Wed, 3 Nov 2021, Jiufu Guo wrote:
>
>> Richard Biener writes:
>>
>> > On Mon, 1 Nov 2021, Jiufu Guo wrote:
>> >
>> >> PR101145 is supporting if the number of iterations can be calculated
>> >> for the 'until wrap' condition. Current test cases are checking if
>> >>
PR101145 is supporting if the number of iterations can be calculated
for the 'until wrap' condition. Current test cases are checking if
the loop can be vectorized, if a loop can be vectorized then the number
of interations is known. While it would be better to check the loop's
number of
Jiufu Guo writes:
> Richard Biener writes:
>
>> On Mon, 18 Oct 2021, Jiufu Guo wrote:
>>
>>> With reference the discussions in:
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574334.html
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572006.html
>>>
Jiufu Guo writes:
> Jiufu Guo writes:
>
>> Richard Biener writes:
>>
>>> On Mon, 18 Oct 2021, Jiufu Guo wrote:
>>>
With reference the discussions in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574334.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572006.html
Richard Biener writes:
> On Mon, 18 Oct 2021, Jiufu Guo wrote:
>
>> With reference the discussions in:
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574334.html
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572006.html
>>
Jeff Law writes:
On 7/15/2021 4:08 AM, Jiufu Guo via Gcc-patches wrote:
Refine code for V2 according to review comments:
* Use if check instead assert, and refine assert
* Use better RE check for test case, e.g. (?n)/(?p)
* Use better wording for target.def
Currently, doloop.xx variable
Richard Biener writes:
> On Thu, 13 Jan 2022, guojiufu wrote:
>
>> On 2022-01-03 22:30, Richard Biener wrote:
>> > On Wed, 22 Dec 2021, Jiufu Guo wrote:
>> >
>> >> Hi,
>> >> ...
>> >>
>> >> Bootstrap and regtest pass on ppc64* and x86_64. Is this ok for trunk?
>> >
>> > So this is a
This is the second patch for two IVs combining.
When one IV is chasing another one, to make it safe, we should check if
there is wrap/overflow for either IV.
With the assumption, which computed as this patch, the number of iterations
can be caculated, even the no_overflow flag is not updated for
Hi,
Previously, there is discussion in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586460.html
I seperate it as two patches.
This first patch is to avoid negative step when combining two ivs.
The second patch is adding more accurate assumptions.
This patch pass bootstrap and
Richard Biener writes:
> On Fri, 14 Jan 2022, Jiufu Guo wrote:
>
>> Richard Biener writes:
>>
>> > On Thu, 13 Jan 2022, guojiufu wrote:
>> >
>> >> On 2022-01-03 22:30, Richard Biener wrote:
>> >> > On Wed, 22 Dec 2021, Jiufu Guo wrote:
>> >> >
>> >> >> Hi,
>> >> >> ...
>> >> >>
>> >> >>
Jiufu Guo writes:
Hi!
> Hi Sehger,
>
> Segher Boessenkool writes:
>
>> On Tue, Mar 01, 2022 at 10:28:57PM +0800, Jiufu Guo wrote:
>>> Segher Boessenkool writes:
>>> > No. insn_cost is only for correct, existing instructions, not for
>>> > made-up nonsense. I created insn_cost precisely to
When checking eq/neq with a constant which has only 16bits, then it can
be optimized to check the rotated data. By this, the constant building
is optimized.
As the example in PR103743:
For "in == 0x8000LL", this patch generates:
rotldi %r3,%r3,16
cmpldi %cr0,%r3,32768
Hi!
Richard Biener writes:
> On Thu, 10 Mar 2022, Jiufu Guo wrote:
>
>>
>> Hi!
>>
>> Richard Biener writes:
>>
>> > On Wed, 9 Mar 2022, Jiufu Guo wrote:
>> >
>> >>
>> >> Hi!
>> >>
>> >> Richard Biener writes:
>> >>
>> >> > On Tue, 8 Mar 2022, Jiufu Guo wrote:
>> >> >
>> >> >> Jiufu
Hi!
Richard Biener writes:
> On Tue, 8 Mar 2022, Jiufu Guo wrote:
>
>> Jiufu Guo writes:
>>
>> Hi!
>>
>> > Hi Sehger,
>> >
>> > Segher Boessenkool writes:
>> >
>> >> On Tue, Mar 01, 2022 at 10:28:57PM +0800, Jiufu Guo wrote:
>> >>> Segher Boessenkool writes:
>> >>> > No. insn_cost is
Hi!
Richard Biener writes:
> On Wed, 9 Mar 2022, Jiufu Guo wrote:
>
>>
>> Hi!
>>
>> Richard Biener writes:
>>
>> > On Tue, 8 Mar 2022, Jiufu Guo wrote:
>> >
>> >> Jiufu Guo writes:
>> >>
>> >> Hi!
>> >>
>> >> > Hi Sehger,
>> >> >
>> >> > Segher Boessenkool writes:
>> >> >
>> >> >> On
Segher Boessenkool writes:
> On Wed, Feb 23, 2022 at 07:32:55PM +0800, guojiufu wrote:
>> >We already have TARGET_INSN_COST which you could ask for a cost.
>> >Like if we'd have a single_set then just temporarily substitute
>> >the RHS with the candidate and cost the insns and compare against
>>
Segher Boessenkool writes:
> On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Biener wrote:
>> I'm assuming we're always dealing with
>>
>> (set (reg:MODE ..) )
>>
>> here and CSE is not substituting into random places of an
>> instruction(?). I don't know what 'rtx_cost' should evaluate
Jiufu Guo via Gcc-patches writes:
> Segher Boessenkool writes:
>
>> On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Biener wrote:
>>> I'm assuming we're always dealing with
>>>
>>> (set (reg:MODE ..) )
>>>
>>> here and CSE is
Richard Biener writes:
> On Thu, 24 Feb 2022, Jiufu Guo wrote:
>
>> Jiufu Guo via Gcc-patches writes:
>>
>> > Segher Boessenkool writes:
>> >
>> >> On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Biener wrote:
>> >>> I'm ass
Richard Biener writes:
> On Fri, 25 Feb 2022, Jiufu Guo wrote:
>
>> Richard Biener writes:
>>
>> > On Fri, 25 Feb 2022, Jiufu Guo wrote:
>> >
>> >> Richard Biener writes:
>> >>
>> >> > On Thu, 24 Fe
Segher Boessenkool writes:
> On Thu, Feb 24, 2022 at 09:50:28AM +0100, Richard Biener wrote:
>> On Thu, 24 Feb 2022, Jiufu Guo wrote:
>> > And another thing as Segher pointed out, CSE is doing too
>> > much work. It may be ok to separate the constant handling
>> > logic from CSE.
>>
>> Not
Hi,
For constants, there are some codes to check: if it is able to put
to instruction as an immediate operand or it is profitable to load from
mem. There are still some places that could be improved for platforms.
This patch could handle PR63281/57836. This patch does not change
too much on
Segher Boessenkool writes:
Hi!
> Hi!
>
> On Thu, Feb 24, 2022 at 03:48:54PM +0800, Jiufu Guo wrote:
>> Segher Boessenkool writes:
>> > That is the problem yes. You need insns to call insn_cost on. You can
>> > look in combine.c:combine_validate_cost to see how this can be done; but
>> > you
1 - 100 of 386 matches
Mail list logo
